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ABSTRACT 


Transfer  of  operational  computer  programs  during  changes  from 
one  computing  system  to  another  presents  a  serious  problem 
throughout  the  industry.  Duplication  of  software  and  reprogram¬ 
ming  necessary  to  support  the  data  processing  activity  must  be 
minimized.  This  document  is  the  result  of  International  Computer 
Systems,  Inc.'s  investigation  into  design  and  documentation 
techniques  for  easing  the  transfer  of  programs  from  one  comput¬ 
ing  environment  to  another. 

The  first  part  of  the  study  is  concerned  with  a  general  trans¬ 
ferability  analysis  and  discussion  of  techniques  to  be  utilized 
independent  of  any  particular  programming  language.  Emphasis  is 
placed  on  the  importance  of  transferability  considerations  dur¬ 
ing  design  and  coding  of  the  problem  program. 

The  second  section  of  the  study  deals  with  higher  level  and 
p-sembly /macro  languages.  Specific  suggestions  for  improvement 
z  FORTRAN,  JOVIAL  and  COBOL  program  design  are  included. 


TECHNICAL  EVALUATION 


1.  This  effort.  Programming  for  Transferability,  was  undertaken  to 
establish  guidelines  to  be  used  In  writing  computer  programs  for  a  given 
computing  environment  that  would  ease  the  transfer  of  these  programs 

to  another  system  with  minimum  reprogramming  effort. 

2.  In  the  past,  software  has  been  machine-dependent.  When  the  user  of 
these  programing  systems  must  change  to  a  new  computing  environment, 

he  must  convert  all  his  existing  programs.  Often,  the  conversion  consists 
of  a  complete  redesign  before  his  programs  will  run  on  the  new  system.  This 
process  Is  very  expensive  and  must  be  corrected. 

3.  In  an  attempt  to  rectify  this  condition.  (Ref  RAOC  TPO  4),  RADC 
decided  to  conduct  an  Investigation  of  the  characteristics  of  the 
various  languages.  This  study  resulted  In  the  establishment  of 
guidelines  for  the  Identification  and  separation  of  the  machine-dependent 
functions  from  the  machine-independent  ones. 

4.  This  effort  provides  the  tools  to  be  used  In  the  Isolation  of  these 
functions  Into  different  modules.  If  a  programmer  must  use  the  machine 
dependent  functions,  only  this  module  must  be  reprogrammed;  thus,  providing 
a  reduction  In  cost  of  transferring  programs  from  one  system  to  another. 

jlMES  A.  MCNEELY  / 

'Project  Engineer 
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SECTION  1.  COMPUTER  PROGRAM  TRANSFERABILITY  ANALYSIS 


1.1  INTRODUCTION 

1.1.1  The  Problem  of  Transferability 

Transferability  is  a  measure  of  the  ease  of  moving  a  computer 
program  from  one  computing  environment  to  another.  Thus,  if  a 
program  needs  to  be  totally  redesigned  and  coded  when  moved  to 
a  new  computer,  it  has  zero  transferability.  On  the  other  hand, 
if  a  program  can  be  moved  to,  and  operate  upon  a  new  computer 
with  no  additional  programming  effort,  it  is  100%  transferable 
between  those  computers.  The  degree  of  transferability  of  a 
program  can  refer  to  the  specific  case  of  two  known  computers 
or  the  general  case  where  the  new  machine  is  unspecified.  Un¬ 
fortunately,  in  both  instances,  the  amount  of  success  encounter¬ 
ed  is  often  very  small.  There  is  promise,  however,  that  tech¬ 
niques  may  be  developed  which  will  significantly  improve  this 
situation. 

Many  factors  affect  a  program's  transferability.  These  include 
the  specific  computers  involved,  the  level  of  language  used, 
the  particular  program  application,  and  the  techniques  used  in 
creating  the  original  program  design.  For  some  of  these  fac¬ 
tors,  it  is  difficult  to  anticipate  the  requirements,  and  thus 
difficult  to  plan  for  ultimate  program  portability*  Other 
aspects  are  more  under  the  programmer's  control  and  thus  more 
conducive  to  planning.  Nevertheless,  even  in  those  areas  sub¬ 
ject  to  improvement,  little  concentrated  effort  has  been  expend¬ 
ed  towards  achieving  a  high  degree  of  program  transferability. 

In  general,  the  data  processing  community  continues  to  be  bur¬ 
dened  by  the  apparent  inability  or  unwillingness  of  computer 
manufacturers  to  produce  greater  computer  compatibility  among 
different  machines.  Some  manufacturers  have  taken  the  initial 
steps  towards  compatibility  among  their  own  computer  models 
while  others  have  failed  to  take  even  this  step  to  any  meaning¬ 
ful  degree.  Meanwhile,  compatibility  among  computers  of  differ¬ 
ing  manufacturers  is  virtually  nonexistent  except  in  a  very  few 
specific  cases. 

Software  technology  has  also  failed  to  produce  sufficient 
progress  towards  alleviation  of  the  program  transfer 
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problem.  The  industry's  costs  associated  with  program  transfer- 
ability  have  proliferated  because  no  significant  agency  has 
provided  the  impetus  for  meaningful  research  in  this  area. 

The  software  community  has  not  provided  the  necessary  guidelines 
or  standards  for  program  design,  coding  and  documentation,  and 
the  hardware  community  has  not  provided  equipment  compatibility. 

The  lack  of  compatibility  or  standardization  has  cost  government, 
the  military  and  the  business  community  huge  sums  for  reprogram¬ 
ming  and  conversion.  Similar  losses  are  incurred  due  to  contin¬ 
ued  usage  of  obsolescent  equipment  that  must  be  retained  because 
undertaking  program  library  conversion  would  be  too  expensive 
and  time  consuming.  The  cost  and  time  involved  in  making  such 
transfers  can  seriously  affect  the  feasibility  and  profitability 
of  the  systems  involved.  Every  aspect  of  the  computing  environ¬ 
ment  may  be  affected  in  some  way. 

•  Personnel  may  need  retraining,  including  programmers , 
operators,  data  clerks  and  end  users. 

•  The  logical  and  physical  form  and  flow  of  data  may 
have  to  be  altered  (peripherals  and  computers). 

•  The  overall  processing  strategy  may  change  (job 
control) . 

•  The  operational  software  may  need  extensive  internal 
modifications . 

Frequently,  when  transfer  of  a  program  is  mandatory  and  after 
exploration  of  all  thfe  alternatives,  a  decision  to  recode  the 
program  is  made.  At  this  point,  unnecessary  costs  are  often 
.  r,  urred  because  of  inadequate  documentation  of  the  original 
d"’  i.gn  of  the  program  and  the  high  rate  of  employee  turnover 
in  the  computer  industry.  Whereas  reprogramming  costs  should 
be  only  a  fraction  of  the  original  expenditures,  more  often 
they  are  very  comparable. 

Formalization  of  design  and  documentation  procedures  and 
recommendations  specifically  directed  towards  facilitating 
program  transferability  are  steps  that  have  been  neglected  by 
the  data  processing  industry. 

The  purpose  of  this  document  is  to  suggest  guidelines  for  con¬ 
trolling  the  cost  and  improving  the  efficiency  of  future  program 
transfers. 
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1.1.2  Methods  of  Transferring  Programs 

This  section  lists  and  discusses  existing  methods  of  implement¬ 
ing  transferable  programs.  The  discussions  are  intended  to 
expose  factors  that  make  transfer  expensive. 

The  methods  discussed  are: 

•  Programming  in  a  higher  level  language 
o  Manual  and  automatic  code  conversion 

•  Interpretive  techniques 

•  Macro  languages 

•  Rewrite 

Since  it  is  unlikely  that  a  competitive  new  method  that  will 
revolutionalize  all  transferability  problems  will  appear  in 
the  immediate  future,  this  document  focuses  on  improving  the 
applicability  and  reducing  the  cost  of  existing  methods. 

Section  2  of  this  document  discusses  three  higher  level  lan¬ 
guages:  FORTRAN,  COBOL  and  JOVIAL.  The  syntax  and  semantics 
of  these  and  other  higher  level  languages,  by  design  and  evolu¬ 
tion,  facilitate  their  translation  into  the  language  of  nearly 
any  machine.  Conversely,  competitive  advantage  dictates  that 
future  machines  will  have  the  features  and  organization  required 
to  run  programs  written  in  higher  level  languages.  As  a  result, 
some  programs  written  in  higher  level  languages  can  be  trans¬ 
ferred  almost  automatically  to  any  machine  for  which  the 
particular  compiler  exists.  Exceptions  to  fully  automatic 
transferability  arise  for  a  variety  of  reasons: 

•  There  has  been  little  pressure  to  avoid  non-standard 
implementations  -  the  apparent  advantages  of  improv¬ 
ing  the  languages  outweighed  the  disadvantages  of 
creating  incompatibilities. 

•  Standard  specifications  have  been  variously 
interpreted. 

•  Even  the  standards  permit  certain  details  to  be 
machine/system  dependent. 
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•  Certain  environmental  conditions  cannot  be 
standardized. 

The  normal  method  of  transferring  programs  written  in  higher 
level  languages  is  to  provide  and  use  "similar"  compilers  for 
the  new  machines  and  cope  with  the  differences.  Often  a  small 
percentage  of  statements  must  be  found  and  manually  replaced 
or  altered.  When  a  popular  version  of  a  language  is  replaced 
by  an  improved  or  standard  version,  an  automatic  conversion  aid 
might  be  developed.  An  example  is  SIFT,  which  converts  FORTRAN 
II  to  FORTRAN  IV. 

In  regard  to  higher  level  languages,  the  intent  of  this  docu¬ 
ment  is  to  help  avoid  or  isolate  those  usages  which  may  be 
incompatible  01  non-transferable . 

The  low  cost  of  transferring  higher  level  language  programs 
depends  on  the  availability  of  a  broadly- amortized  compiler 
for  the  new  machine.  If  an  unpopular  higher  level  language  is 
chosen,  a  user  may  have  to  unilaterally  bear  the  burden  of  new 
software  development  for  the  sake  of  transfer. 

Manual  and • automatic  code  conversion  is  usually  applied  to  con¬ 
verting  assembly  language  source  code  to  the  source  code  for  a 
different  language,  either  the  assembly  language  of  a  different 
machine  or  a  higher  level  language. 

Assembly  languages  are  designed  for  a  particular  machine  and 
provide  some  way  of  specifying  every  function  and  combination 
of  functions  that  machine  may  perforr.  Assembly  languages  are 
most  often  used  when  no  compiler  exists  for  the  machine:  ~o 
specify  functions  not  contained  in  the  higher  level  languages; 
to  avoid  some  highly  general  and  hence  inefficient  code  genera¬ 
ted  by  compilers;  or  to  avoid  interference  between  compiler 
output  and  the  desired  program,  (e.g.  a  FORTRAN  editor- loader 
written  in  FORTRAN  would  have  to  be  very  carefully  designed  to 
stay  out  cf  its  own  way) . 

The  actual  method  of  transferring  by  code  conversion  is  as 
follows : 

•  Determine  a  realise'  development  budget  for  the 
converter  program. 

•  For  each  aspect  of  the  source  language,  design  a 
destination  language  equivalent.  Unfortunately 
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this  is  not  usually  an  instruction  for  instruction 
equivalence. 

•  Select  those  aspects  that  can  be  handled  within 
development  budget  or  other  constraints.  Develop 

a  program  that  will  read  source  machine  code.  Iden¬ 
tify  aspects  and  extract  parameters,  either  flagging 
troublesome  aspects  for  manual  attention  or  'punching' 
the  chosen  target  machine  equivalent  source  code. 

The  wide  disparity  among  computer  architectures,  especially  with 
regard  to  addressing  schemes,  may  often  make  it  virtually  impos¬ 
sible  to  design  an  effective  program  conversion  tool.  Typically, 
in  this  situation,  only  the  invention  of  very  clever  correspond¬ 
ence  algorithms  can  help  to  produce  even  partially  efficient 
code  conversion.  For  this  reason,  automatic  conversion  tools 
are  sometimes  only  last  resort  or  after-the-fact  efforts  at 
program  transfer. 

Assuming  that  automatic  conversion  is  possible,  the  process  of 
converting  a  program  then  entails  the  following  steps: 

•%  Manually  edit  the  input  source  code,  deleting  or 
replacing  functions  that  are  unnecessary  or  in¬ 
appropriate  in  the  destination  syster., 

•  Process  the  program  via  the  converter. 

•  Debug  the  result,  manually  editing  the  converter 
output  using  the  warning  and  error  flags  provided 
by  the  converter,  plus  the  ordinary  test  and  de¬ 
bug  procedures  and  aids. 

•  Check-out  the  program  on  new  system. 

Maurice  Halstead,  in  "Using  the  Computer  for  Program  Conversion", 
Datamation,  May  1970,  discusses  the  economics  of  amortizing  a 
conversion  aid  program  called  a  decompiler.  He  points  out  that 
a  conversion  aid  handles  the  easier  parts  of  conversion.  To 
improve  a  conversion  aid  by  50%  to  100%  of  its  current  capabil¬ 
ity  requires  as  much  additional  effort  as  has  already  been 
expended.  The  residue  needing  manual  conversion  is  increasingly 
difficult.  As  a  result,  a  conversion  aid  appears  to  be  fairly 
expensive  before  it  becomes  worthwhile,  and  must  be  amortized 
over  a  large  workload.  Furthermore,  some  degree  of  manual 
re-coding  will  amost  always  be  required. 
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Figure  1  on  the  following  page  shows  Halstead's  conclusions  in 
graph  form.  Note  that  the  units  cannot  be  arbitrarily  chosen; 

16  units  of  development  effort  corresponds  to  a  converter  that 
will  handle  96%  of  the  input  code.  If  it  is  estimated  that  32 
man  weeks  would  be  required  to  do  a  96%  converter,  then  the 
units  are  2  manweeks. 

In  another  area,  interpretive  techniques,  several  software 
products  on  the  market  are  economically  viable  because  they 
are  usable  on  and  for  a  variety  of  machines.  These  techniques 
have  been  used  to  produce  transferable  meta-assemblers,  com¬ 
pilers,  and  application  packages. 

The  products  themselves  are  written  in  special  languages  usually 
designed  for  two  properties:  The  language  is  optimized  for  the 
convenient  expression  of  facilities  needed  by  the  software  pro¬ 
duct,  and  the  language  may  be  easily  interpreted  for  a  large 
number  of  machines  in  the  anticipated  market.  The  language  is 
usually  similar  in  format  to  an  assembly  language  for  a  machine 
that  would  be  ideal  for  the  application. 

To  have  such  a  software  product  running  on  a  new  machine  usually 
requires  only  a  few  man  months  to  write  an  interpreter  for  its 
internal  language.  For  example,  International  Computer  Systems' 
DUAL,  a  meta  assembler,  is  implemented  using  a  very  advanced 
interpretive  process.  DUAL  can  be  transferred  to  a  new  machine 
for  2%  of  its  original  development  cost. 

The  transferability  advantage  quite  outweighs  any  loss  of  opera¬ 
ting  speed  (which  can  be  considerable  unless  proper  techniques 
aie  used)  through  interpretive  execution.  Note  that  some  higher 
level  language  compilers  produce  object  code  which  is  largely  a 
series  of  subroutine  calls,  and  that  the  execution  of  such  could 
be  considered  interpretive.  Also,  it  should  be  noted  that  well 
implemented  interpretive  products  can  be  made  to  execute  within 
10-20%  of  efficient  assembly  level  code.  This  is  very  competi¬ 
tive  with  efficient  (optimized)  higher  level  language  compiler 
generated  code. 

The  macro  assembly  concept,  on  the  other  hand,  permits  the  defi¬ 
nition  of  languages  having  some  of  the  transferability  advantages 
of  higher  level  languages  as  the  object  code  efficiency  of  mach¬ 
ine  languages.  Macro  assemblers  allow  users  to  define  ways  in 
which  source  input  is  to  be  processed  into  forms  recognizable 
by  the  assembler.  To  the  extent  that  existing  assemblers  allow 
a  common  macro  invocation  format,  a  program  written  as  a  sequence 
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Various  triple  address  pseudo-computers,  for  example,  may  be 
utilized  with  one  set  of  macros.  The  code  below  shows  a  simple 
example  of  alternative  expansions. 

ADD  AUGEND, ADDEND, RESULT 

CLA  AUGEND 
ADD  ADDEND 
ST0  RESULT 

or 


L  R, AUGEND 

A  R, ADDEND 

ST  R, RESULT 

This  technique  now  permits  the  coding  of  programs  more  efficient 
and  nearly  as  transferable  as  those  written  in  higher  level 
languages. 

A  final  alternative,  rewriting  a  program  or  part  of  a  program  by 
hand,  might  seem  desperate  but  can  often  be  justified,  especial¬ 
ly  if  there  is  already  strong  incentive  to  re-design  the  program. 
From  Section  1.1.3  the  cost  per  use  of  converted  and  rewritten 
versions  of  the  program  can  be  estimated.  The  cost/use  figures 
can  be  compared  to  the  value/use  estimates  to  give  a  convert/ 
rewrite  decision. 


Dependencies  may  sometimes  be  isolated  in  a  module  (see  Section 
1.3.2  Modularity)  which  is  expected  to  be  rewritten.  If  such 
modules  form  only  a  small  percentage  of  the  total  program  while 
still  absorbing  a  large  part  of  the  dependencies  of  the  program, 
cost  savings  may  result. 


1.1.3  Transferability  Economics 


The  natural  figure  of  merit  by  which  any  transfer  effort  or 
technique  may  be  judged  is  its  cost  effectiveness,  specifically, 
the  cost  per  use  of  the  transferred  unit.  This  document  does 
not  define  effectiveness  in  any  other  way;  it  simply  assumes 
that  transfer  is  completed  when  the  end  user  is  as  satisfied 
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with  the  result  as  he  was  before  the  transfer.  It  may  happen 
that  for  a  particular  case  an  incomplete  transfer  may  give  better 
overall  results.  That  is,  there  may  be  a  more  complete  defini¬ 
tion  of  effectiveness.  Also,  this  analysis  makes  no  assumptions 
about  whether  cost/use  is  greater  or  less  than  value/use. 

Finally,  it  is  assumed  that  the  machine  or  system  which  is  the 
destination  of  a  transfer  is  itself  no  more  and  no  less  cost 
effective  than  the  original,  source  machine  or  system.  Manage¬ 
ment  must  assign  its  own  weighing  factors  to  the  figures  derived 
from  this  analysis. 

In  the  following  sections  some  simple  formulas  are  presented 
along  with  tables  containing  estimates  of  relative  values  for 
substitution  in  the  formulas.  Some  of  these  estimates  are  brok¬ 
en  down  into  more  detail  later.  Many  of  the  suggestions  pre¬ 
sented  include  relative  cost  factors  associated  with  system 
transfer  and  continued  operation.  In  fact,  the  guidelines 
presented  are  those  for  which  the  cost  factors  are  the  most 
"ignificant. 

-ogram  conversion  is  a  combination  of  manual  and  automatic 
processes.  For  assembly  language  in  particular,  the  automatic 
processing  is  done  by  a  fairly  expensive  program  which  must  be 
amortized  over  a  large  pool  or  program  conversions.  Existing 
conversion  aids  were  designed  to  process  a  pool  of  programs 
which  may  not  have  been  conditioned  by  application  of  the  guide¬ 
lines  presented  in  this  document;  hence  the  conversion  aids  are 
more  complex  and  expensive  than  they  would  need  to  be  to  process 
well-conditioned  programs.  Amortization  accounting  or  pricing 
policies  infer  that  programs  that  have  been  designed  and  coded 
for  ease  of  transfer  may  not  get  the  price  break  they  deserve 
until  there  is  a  large  enough  pool  of  well-conditioned  programs 
to  support  cheaper  conversion  aids.  On  the  other  hand,  the  cost 
of  the  manual  part  of  the  conversion  process  can  be  reduced 
immediately.  Steps  may  be  taken  to  reduce  the  amount  of  manual 
work  (avoiding  usages  that  the  automatic  process  cannot  handle) 
and  documentation  may  be  prepared  to  make  the  manual  steps  easier 
to  follow.  This  may  be  of  no  benefit,  however,  when  the  price 
of  the  manual  work  is  fixed  at  so  much  per  card  in  the  whole 
program  and  established  for  a  work  mix  including  ill-conditioned 
programs.  Most  commercial  conversion  services  do  offer  an 
option  under  which  the  customer  does  the  manual  work.  For 
well-conditioned  programs  this  is  probably  advantageous. 

The  cost  for  each  use  of  a  program  is  the  amortized  program 
preparation  cost  plus  the  operating  cost: 


CU  =  P/N  +  0 


In  this  formula, 

CU  =  Cost  per  use 

N  =  The  number  of  uses  of  the  program,  usually  pro¬ 
jected  when  estimating  a  preparation  policy. 

P  =  The  preparation  cost.  This  and  operating  cost 
will  be  broken  down  by  method  of  preparation,  by 
component  programming  task,  by  language  and  by 
application  area. 

0  ■  The  cost  of  operating  the  program,  both  direct 
and  indirect  (e.g.  requirement  for  additional 
core  storage) . 

Three  levels  of  program  preparation  for  system  transfer  are 
distinguished  for  estimating  purposes: 

•  Design  and  code  from  problem  statement  (complete 
re-write) . 

•  Code  from  existing  design  (design  transfer) . 

•  Transfer  the  program  largely  intact  (code 
transfer) . 

The  following  tables  give  general  estimates  of  the  relative  costs 
associated  with  these  techniques.  For  example,  in  Table  1A  the 
least  costly  approach  is  to  transfer  a  COBOL  program  from  one 
system  to  another.  Similarly,  it  is  about  1-1/3  times  as  expen¬ 
sive  to  re-code  a  program  in  assembly  language  as  it  is  in 
COBOL.  All  of  these  figures  depend  on  the  particular  problem 
program,  system  being  used,  etc.  They  are  intended  only  to 
indicate  a  general  feeling  for  the  relative  costs  most  often 
incurred. 

The  10/1  ratio  for  level  1/level  3  preparation  of  assembly 
language  material,  for  instance,  is  simply  the  ratio  $10/card 
(a  widely  used  but  unsubstantiated  estimate)  to  a  $ 1/card  aver¬ 
age  charge  for  conversion  services  (see  Appendix  C).  Note  that 
the  figures  are  related  to  each  other  only  within  a  table  and 
not  between  tables.  Hence,  the  ratio  of  programming  to  operat¬ 
ing  costs  is  not  estimated  and  is  really  peculiar  to  each 
program  and  machine. 
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TABLE  1A 


Program  Transfer  Preparation  Costs 

COBOL  FORTRAN  JOVIAL  ASSEMBLY 

Re-write  75  60  60  100 

Design  Transfer  40  20  30  60 

Code  Transfer  1  2  5  10 

The  preparation  cost  of  transferring  code  can  oe  furth~  : 
analyzed: 

•  Cost  =  A  +  0  +  (  I  C  +  W)  *N 

This  includes  automatic  costs  -  the  costs  of  use  of  a  conversion 
aid  are: 

A  =  Amortized  development  cost 
O  =  Operating  cost 

and  manual  costs  -  the  costs  of  manual  work  are  those  of: 

I  =  Identifying  exceptions  t>_  automatic  conversion 
C  =  Comprehending  exception  code 
W  =  Writing  target  machine  equivalents 

These  are  all  multiplied  by: 

N  =  The  number  of  exceptions. 

It  is  important  to  note  that  there  are  three  classes  of 
exceptions : 

•  Those  the  converter  can  identify,  but  not  deal  with. 

•  Those  the  converter  can  flag  as  potential  problems. 

•  Those  that  escape  identification  by  the  converter. 
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TABLE  IB 


Program  Operating  Costs  After  Transfer 


COBOL 

FORTRAN 

JOVIAL 

ASSEMBLY 

Re-write 

90 

60 

50 

20 

Design  Transfer 

90 

65 

50 

30 

Code  Transfer 

100 

65 

70 

50 

The  excess  cost  of  operating  transferred  code  is  a  result  of 

•  Original  code  not  needed  in  the  new  environment  - 
usually  because  it  is  included  in  the  operatirg 
system  or  in  the  new  programming  language  library. 

•  Simulation  of  the  methods  by  which  the  original 
machine  performed  a  function,,  rather  than  duplica¬ 
tion  of  that  function. 
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lc  2  MANAGEMENT  POLICIES 


1.2.1  Introduction 

Several  items  to  be  considered  in  the  formulation  of  a  transfer- 
ability  policy  were  presented  in  the  previous  section  with 
suggestions  for  an  orderly  weighing  of  alternatives-  A  concrete 
plan  for  the  further  formalization,  application  and  enforcement 
of  this  policy  must  now  be  developed.  Many  questions  remain  to 
be  resolved  by  management  before  such  a  plan  can  be  implemented. 


1.2.2  Policy  Formulation 


A  complete  transferability  policy  requires  an  initial  statement 
of  goals  and  an  outline  of  the  .methods  to  be  used  in  their  full- 
fillment.  Transferability  considerations  are  first  to  be  listed 
along  with  the  basic  project  purposes,  usually  by  the  manager 
responsible  for  the  programming  budget.  Realistic  transfer- 
ability  depends  not  only  upon  the  available  standards  and  guide¬ 
lines  but  also  upon  the  judgment  and  experience  of  this 
individual . 


The  competitive  elements  of  initial  cost,  operating  cost,  future 
cost,  scheduling  and  general  project  feasibility  must  be  care¬ 
fully  analyzed  and  balanced  by  the  manager.  Then,  the  methods 
proposed  for  attainment  of  the  desired  results  must  be  carefully 
outlined.  Initially,  it  is  important  to  determine  the  avail¬ 
ability  and  practicality  of  these  techniques  and  to  realize  to 
what  extent  they  will  effect  costs.  Later,  they  may  be  refined 
as  part  of  the  ordinary  design  process.  Explicit  directions 
and  constraints  ara  thus  laid  down  for  subsequent  workers.  The 
level  of  detail  should  leave  options,  but  not  doubts.  Uniform¬ 
ity  across  several  program  projects  may  be  a  very  important 
subgoal  in  that  it  can  spread  the  amortization  of  conversion 
aids  and  training.  Hence,  many  of  the  basic  aspects  of  program 
design  must  be  delineated  by  management  if  an  organized,  coor¬ 
dinated  transferability  effort  is  to  be  realized. 


The  following  questions  should  be  considered  in  formulating  a 
transferability  policy.  Although  they  are  listed  roughly  in 
order  of  inquiry,  not  all  of  them  may  always  be  applicable. 

•  How  important  is  transferability? 
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•  Where  does  transferability  rank  among: 

.  Meeting  a  tight  deadline? 

.  Meeting  a  tight  budget? 

.  Accomplishing  a  demanding  development  effort? 

•  What  is  the  probability  of  future  transfers? 

•  Do  other  decisions  reflect  the  stated  importance  of 
transferability? 

•  Do  schedules  and  budgets  allow  for  the  thorough, 
thoughtful  job  necessary? 

(Remember  that  if  a  program  never  attains  executability , 
its  other  attributes  are  irrelevant.  For  this  reason 
transferability  (and  maintainability  and  reliability) 
are  at  best  secondary  goals  which  will  be  squeezed  out 
by  unrealistically  tight  scheduling.) 

•  What  effect  will  choice  of  computing  system  have  upon 
transferability? 

.  Regarding  transfers  to  the  system? 

.  Regarding  future  transfers  from  the  system? 

•  Does  the  system  seem  to  be  in  the  main  stream  of 
computing  development?  How  similar  are  the  probable 
transfer  target  machines? 

•  In  choosing  a  language,  where  does  transferability 
rank  among: 

.  Convenience  of  the  lang  uige? 

.  Applicability  of  the  language? 

.  Familiarity  of  the  language? 

.  Conformation  with  shop  practice? 

•  What  restrictions  must  be  placed  upon  the  usage  of 
the  language?  Does  a  recognized  standard  exist  and 
should  it  be  used?  Should  extensions  be  used? 

•  Is  the  la  .,uage  still  applicable  with  the  restrictions? 

•  What  methods  will  be  used  to  effect  a  transfer? 
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•  What  aspects  of  the  system  ?end  themselves  to  program 
parameterization? 

•  Is  the  overall  design  of  the  program  (or  system  of 
programs)  suited  to  the  selected  transfer  method? 

•  Should  a  library  of  system  dependent  routines  be 
developed  and  what  should  it  contain? 

1.2.3  Policy  Enforcement 

In  the  programming  environment,  policy  enforcement  efforts  may 
be  focused  on  the  following  four  areas: 

•  Task  sequencing  and  emphasis 

&  Conflict  between  policy  and  practice 

•  Conflict  between  policy  and  technology 

•  Attention  to  details 

There  is  a  natural  order  for  the  performance  of  the  subtasks 
in  producing  a  program.  A  subtask  is  easier  if  performed 
while  the  information  required  is  fresh  from  a  previous  or  con¬ 
current  subtask.  This  is  particularly  true  of  documentation. 
The  information  contained  in  the  documentation  is  substantially 
the  same  as  that  produced  and  required  for  design  and  code.  In 
fact,  projects  large  enough  to  be  deemed  difficult  are  probably 
best  done  by  producing  meaningful  documentation  at:  each  step. 
Successive  steps  may  then  be  guided  by  prt/ious  documentation. 

In  addition,  postponed  subtasks  may  seem  anticlimatic  and  thus 
present  morale  problems  when  resumed.  Hence,  little  should  re¬ 
main  to  be  done  after  the  program  is  checked  out.  Very  few 
programmers  care  to  work  on  a  project  after  ’-'art  of  the  staff 
have  gone  on  to  other  things. 

Once  the  subtasks  are  scheduled,  each  should  be  appropriately 
emphasized  and  carried  to  completion  in  its  turn.  (Some  sub¬ 
tasks  may  be  concurrent.)  Whatever  level  of  supervision  is 
appropriate  should  be  maintained. 

Day-to-day  management  decisions  constitute  the  actual  manage¬ 
ment  policy  which  may  not  in  fact  agree  with  the  stated  policy. 
Such  decisions,  therefore,  should  be  examined  for  agreement 
with  policy  statements.  One  or  the  other  may  require  change. 

Policy  may  well  be  translated  into  statements  of  the  expected 
performance  rewards  or  penalties.  In  rewarding  programmer 
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performance,  watch  out  for  visible  results  achieved  at  the 
expense  of  less  visible  factors.  If  transferability  is  a  goal, 
a  piece  of  work  may  be  finally  evaluated  only  when  transfer  is 
attempted.  If  you  reward  a  programmer  for  meeting  a  tight 
deadline,  and  penalize  a  maintenance  programmer  for  finding  the 
result  difficult  to  deal  with,  morale  suffers  and  maintain¬ 
ability/transferability  policies  do  not  in  fact  have  management 
support . 

It  is  best  to  reward  the  programmer  whose  work  most  accurately 
fulfills  the  goals  set  for  the  project. 

Beware  of  trying  to  translate  goals  into  a  blanket  set  of  rules 
once  and  for  all.  If  the  rules  are  not  in  fact  the  best  way  of 
meeting  the  goals,  or  if  they  become  less  than  germane  as  time 
goes  on,  programmers  will  be  frustrated  and  alienated.  At  least 
a  periodic  review  of  the  rules  is  needed. 

Moreover,  defined  requirements  can  be  obeyed  without  actually 
fulfilling  their  purpose.  An  example  is  a  program  listing 
which  contains  the  amount  (percentage,  number  of  lines,  etc.) 
of  comments  and  documentation  required  by  management  without 
conveying  much  understanding  of  the  program.  Documentation 
beyond  the  programmer's  ability  to  communicate  is  v/asted  and 
harmful. 

The  coding  of  a  program  sometimes  exposes  weaknesses  in  its 
design.  Hence,  it  may  be  found  infeasible  to  code  a  program 
without  certain  transferability  constraints,  particularly  if 
those  constraints  were  established  without  consideration  of 
the  programming  problem  at  hand. 

If  the  transferability  policy  was  established  independently  of 
a  particular  program  or  project,  it  can  probably  be  redesigned 
and  other  methods  found.  If  the  policy  was  established  for  a 
larger  system  uniformly,  the  program  in  trouble  may  have  to  be¬ 
come  an  exception. 

Even  well  documented  transferability  practices  may  get  lost  in 
a  welter  of  details.  This  is  particularly  true  if  a  programmer 
is  inclined  to  take  shortcuts  or  make  ill-advised  "improvements" 
on  the  policy.  Unfortunately,  examination  of  programmer  out¬ 
put  for  compliance  is  tedious.  Probably  the  best  way  to  verify 
transferability  is  to  transfer  the  program  immediately,  while 
problems  can  be  more  readily  corrected  and  while  the  results 
can  directly  influence  the  programmer's  future  level  of 
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compensation  and  responsibility.  Immediate  transfer,  of  course, 
is  not  always  possible  or  cost  justifiable. 

The  programming  language  translator  or  precompiler  can  examine 
source  code  for  factors  that  influence  transferability.  When¬ 
ever  possible,  compilers  should  flag  usage  of  any  non-standard 
language  features  that  they  implement.  WATFOR  (Siegel  -  see 
Bibliography  and  Synopsis)  is  an  excellent  example  of  fulfilling 
this  function. 

Presently,  there  are  COBOL  precompilers  that  enforce  management- 
selected  language  usage  constraints.  Information  Management 
Inc.,  for  instance,  has  Magic  Standards  Enforcer  which  notes 
use  of  management-prescribed  COBOL  verbs.  Arkay  Computer 
Applications'  MECCA  flags  about  200  management  selected  viola¬ 
tions.  Although  largely  oriented  toward  uniformity  of  the 
listings  for  the  sake  of  readability,  such  products  usually 
can  flag  use  of  any  selected  reserved  words.  These  standard 
enforcement  packages  are  generally  machine  specific,  however, 
and  thus  non-transf erable  in  themselves. 

In  the  selection  and  use  of  standards  enforcement  products  and 
techniques,  it  may  be  wise  to  consider  one  basic  aspect  of  the 
computing  environment.  Namely,  that  programming  originally 
demanded  people  who  ware  clever  and  comfortable  in  an  absence 
of  established  practice.  The  best  of  their  innovations  have 
become  the  current  standards  and  recognized  techniques.  Some 
of  their  efforts,  however,  have  left  an  aura  of  eccentricity 
which  by  now  is  somewhat  misleading.  It  must  be  kept  in  mind, 
therefore,  that  policy  enforcement  is  an  ordinary  management 
problem,  not  a  manager-programmer  adversary  situation. 

All  in  all,  it  is  difficult  to  recommend  a  specific  policy  on 
transferability  which  will  adequately  suit  every  manager's 
needs,  desires,  budget  constraints,  and  personnel  relationships. 
Each  project  or  installation  executive  must  formulate  a  plan  of 
action  pursuant  to  his  particular  operating  environment,  per¬ 
sonality  and  upper  management  dictates.  For  example,  it  was 
recommended  that  after  initial  coding  an  attempt  should  be 
made  at  program  transfer  as  a  test  and  possible  measure  of 
programmer  ability  and  conformance  to  installation  standards. 

In  many  instances  complete  transfer  may  be  untimely,  not  cost- 
effective  or  in  some  other  way  undesirable.  Hence,  the  manager 
may  elect  to  inspect  or  re-compile  a  small  routine  -  section 
(of  his  choice)  or  to  discard  the  technique  entirely. 
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Although  a  wide  variety  of  management  policies  seems  reasonable, 
a  universal  aspect  has  been  shown  to  exist.  Namely,  some  sort 
of  plan  must  be  formulated  and  enforced  if  any  degree  of  program 
transferability  is  to  be  attained. 
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1.3  GENERAL  PROGRAM  DESIGN  GUIDELINES 


1.3.1  Introduction 

This  section  presents  general  guidelines  for  program  design 
approaches  that  will  help  minimize  one  or  more  of  the  transfer 
costs  described  in  Section  1.1.2.  These  guidelines  are  usually 
applicable  independent  of  the  choice  of  coding  languages. 

Transferability  is  sometimes  not  the  major  consideration  in 
program  design.  Fortunatley,  transferability  techniques  sel¬ 
dom  conflict  with  usual  good  design  practices. 

This  following  outline  gives  design  steps  to  use  in  identifying 
transferability  problems  and  chosing  a  method  of  solving  them. 
This  process  goes  on  in  parallel  with  the  ordinary  design  pro¬ 
cess  and  must  be  repeated  as  often  as  necessary  since  there  are 
transferability  considerations  at  each  level  of  detail.  In  a 
few  cases  previous  decisions  must  be  modified  in  light  of  new 
information,  but  this  is  not  unique  to  transferability. 

•  Estimate  the  breakeven  point  for  additional  cost  of 
a  new  program  versus  cost  of  transferring  the  origi¬ 
nal  program. 

•  Identify  the  dependencies.  List  the  factors  which 
may  effect  the  transfer  attempt.  These  may  include 
operating  system  facilities,  hardware  configuration, 
language  and  level  of  language,  I/O  paths,  secondary 
and  primary  storage  characteristics,  data  representa¬ 
tion,  instruction  set,  registers  (if  any),  addressing, 
program  language  features,  etc.  If  such  a  list  is 
prepared  for  an  installation,  save  it  for  future 
reference.  The  list  can  be  made  as  the  design  pro¬ 
gresses,  but  remember  that  it  may  overlook  pertinent 
items  in  the  early  stages  of  design  during  which  it 

is  prepared.  Many  of  the  factors  in  the  list  are 
probably  included  in  Appendix  B. 

•  Categorize  the  items  on  the  list  in  terms  of  their 
impact  upon  transferability.  That  is,  if  the  item 
is  absent  or  different  on  the  next  machine,  one  of 
the  following  applies: 

.  The  function  being  performed  is  no  longer  pertinent. 
.  Redesign  is  required. 

.  Recode  is  required. 
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Code  transfer  is  not  precluded. 

.  Transferability  effort  is  deferred  until  transfer 
time  (for  budget  reasons,  or  if  there  is  a  reason 
to  expect  the  problem  will  never  arise) . 

•  Select  a  way  of  dealing  with  each  of  the  above 

categories.  For  example: 

.  Loss  of  relevance  becomes  a  system  configuration 
constraint. 

.  Redesign  may  be  treated  as  a  system  configuration 
constraint,  or  it  may  be  possible  to  isolate  the 
problem  area  into  a  module  slated  for  redesign. 

.  Items  for  re-code  should  be  isolated  in  modules 
to  limit  their  effects  on  other  areas  (see 
modularity) . 

.  For  untroublesome  functions,  parameterization  and 
use  of  "standard"  code  are  often  enough  to  permit 
program  transfer. 

.  Deferred  items  should  be  isolated. 


1.3.2  Modularity 


Modularity  is  a  formal  way  of  dividing  a  program  into  a  number 
of  subunits  each  having  a  well-defined  function  and  relationship 
to  tne  rest  of  the  program.  There  are  well-known  advantages  in 
modularity;  the  one  of  most  interest  here  is  that  those  program 
functions  which  will  need  the  most  programmer  attention  upon 
transfer  can  often  be  isolated  and  functionally  identified  as 
distinct  modules.  The  modules,  if  organized  and  documented 
properly,  can  be  worked  on  with  little  reference  to,  or  inter¬ 
ference  with,  the  rest  of  the  program.  Less  critical  areas  of 
the  program  can  then  be  converted  using  other,  perhaps  less 
expensive,  methods. 


In  FORTRAN,  modules  may  be  subprograms  which  can  be  compiled 
independently  and  reconnected  to  the  balance  of  the  program  at 
load  time. 


In  JOVIAL  and  COBOL,  the  modules  are  subprograms  and  paragraphs 
respectively . 
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Assembly  languages  are  also  flexible  in  this  regard  although  it 
is  usually  necessary  to  distribute  some  symbol  definitions 
across  modules  that  are  assembled  independently.  This  may  be 
done  either  bv  preloading  the  assembly  symbol  table  (the  COMPOOL 
or  DSECT  concept)  or  by  a  load  time  symbol  table  'the  external 
symbol  concept) . 

An  essential  aspect  of  these  modules  is  their  isolation  from 
the  rest  of  the  program.  Each  section  should  be  a  sequence  of 
programming  language  statements  having  a  well  marked  start  and 
end.  The  function  of  the  module  and  its  interface  with  the 
rest  of  the  program  should  be  simple  and  well  documented.  A 
module  performing  several  closely  related  functions  may  have 
several  entry  points.  However,  one  entry  point  and  a  function 
parameter  branch  is  usually  better  practice.  Similarly,  having 
program  control  enter  a  module  in  the  middle  simply  to  take 
advantage  of  a  convenient  piece  of  code  should  be  avoided.  That 
entry  defines  an  additional  function  for  the  module  which  may  be 
expensive  to  reproduce. 

A  program  should  be  modularized  by  function  and  by  nature  of 
machine/system  dependency.  Modularization  by  function  has  been 
considered  good  practice  in  those  languages  that  facilitate  it. 

The  following  is  a  list  of  modules  into  which  a  majority  of 
programs  may  be  organir  :d.  Each  of  them  should  be  considered 
for  splitting  into  two  modules  -  one  machine/system  independent, 
the  other  containing  the  dependencies.  In  defining  a  machine 
dependent  module,  remember  that  the  object  is  to  render  the 
environment  of  the  independent  modules  invariant  with  respect 
to  transfer: 


General  Program  Modules 

•  Parameterization 

.  Character  sets,  data  masks,  etc. 
Machine  architecture 

•  Initialization 

.  Machine/System 
.  Primary  storage 
.  Program 
.  Files 
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•  Processing 


.  Interrupt  processing 
.  Data  acquisition 
.  Data  editing 

.  Data  organization  (primary  storage) 

.  Computation 

.  Intermediate  secondary  storage  organization 
.  Data  conversion/formatting 
.  Output 

.  Error  checking  and  recovery 

»  Termination 

.  Files 
.  Normal  end 
.  Exceptional  end 

This  modularity  outline  is,  by  the  nature  of  this  discussion, 
very  general  in  concept.  More  specific  suggestions  on  program 
organization  are  presented  in  the  individual  sections  concern¬ 
ing  FORTRAN,  JOVIAL,  COBOL,  and  Assembly  languages. 

1.3.3  Parameterization 

Parameterization  is  a  method  by  which  a  problem  program  may 
self-adjust  to  a  program,  hardware,  or  system  modifications. 

Some  numeric  or  symbolic  items  in  the  program  may  require  altera¬ 
tion  if  the  same  function  is  to  be  performed  in  a  new  environ¬ 
ment.  These  values  may  be  written  into  the  code  explicitly  or 
they  may  be  parameterized.  In  the  latter  case,  symbolic  vari¬ 
ables  are  used  in  place  of  actual  values.  These  symbolic 
variables  are  set  to  the  applicable  values  in  an  initializat:  on 
phase  of  the  program  execution  or  during  assembly/compilatio  . 

The  values  chosen  may  be  directly  initialized  by  programmer 
coding  or  they  may  be  set  up  or  calculated  by  the  language 
processor. 

If  the  value  is  written  in  by  the  programmer,  it  should  be  in 
a  well  marked  statement,  with  all  such  statements  collected  in 
one  place.  The  documentation  for  each  such  value  should  be 
explicit  in  how  and  when  a  new  value  is  to  be  determined  for 
the  parameter.  If  the  value  is  to  be  computed,  the  computation 
must  be  checked  out  for  a  range  of  values. 

Parameterization  may  also  be  used  to  avoid  usages  which  may  not 
be  supported  by  all  compilers  for  a  language.  For  example,  not 
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all  FORTRAN  compilers  support  variable  array  sizes  in  subrou¬ 
tines.  The  usage  may  be  avoided  by  passing  array  sizes  as 
parameters  and  calculating  index  values  (if  multi-dimensional) 
explicitly.  Or,  if  there  is  a  possibility  that  the  organiza¬ 
tion  of  an  array  is  not  standard  (stored  by  rows  rather  than 
columns)  a  switch  can  be  used  to  select  the  appropriate  calcu¬ 
lation.  The  value  of  that  switch  can  be  determined  by  the 
program  during  initialization. 

Some  assemblers  provide  for  conditional  assembly  in  which  the 
value  of  a  parameter,  defined  near  the  start  of  the  program, 
may  be  tested  for  skipping  of  alternative  code  sequences. 

Although  a  transferred  program  usually  performs  an  unaltered 
function  on  the  new  machine,  parameterization  may  be  used  even 
more  extensively  when  the  program  function  is  altered  during 
transfer.  This  is  the  case  for  the  parametric  programming 
language  processors  mentioned  in  Section  1.1.3,  Methods  of 
Transfer. 

Parameterization  requirements  depend  on  the  details  of  the 
programs  involved.  Each  actual  value  in  the  code  must  be  con¬ 
sidered  for  parameterization  as  it  is  being  written.  If  the 
value  and  the  representation  of  that  value  are  independent  of 
any  reasonable  change  in  machine  applications,  scope,  or  langu¬ 
age,  or  if  the  programming  language  does  not  permit  a  symbolic 
value  in  that  context,  then  parameterization  does  not  apply. 

In  general,  over-parameterization  is  rarely  a  problem,  especially 
in  the  assembly  or  compilation  process.  Thus,  the  cost  of 
parameterization  is  nontrivia]  ,nly  if  the  logic  of  the  program 
or  usage  of  the  language  must  be  perverted.  The  value  of  par¬ 
ameterization,  on  the  other  hand,  can  be  considerable.  Indi¬ 
vidual  examples  of  this  fact  are  discussed  in  depth  in  other 
sections . 

1.3.4  Code  Constraints 

Program  transferability  can  be  greatly  enhanced  simply  by  avoid¬ 
ing  code  that  is  difficult  to  transfer.  Finding  and  using 
alternative  code,  however,  does  involve  additional  programming 
costs  which  must  be  measured  against  the  benefits  obtained. 

For  higher  level  languages,  the  primary  code  constraints  of 
concern  involve  the  avoidance  of  language  features  which  are 
apt  to  be  missing  or  altered,  or  which  will  give  different 
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results  when  compiled  on  the  transfer  target.  As  discussed 
in  Section  1.5,  competitive  advantage,  implementor  taste  and 
standardization  ambiguities  contribute  to  lack  of  basic  language 
compatibi li ty . 

The  language  features  most  likely  to  be  missing  or  different  in 
other  compilers  are  the  language  extensions  and  the  expensive  or 
little-used  standard  features.  Unless  a  language  was  specific¬ 
ally  extended  to  suit  an  application,  use  of  extensions  can  be 
avoided  with  only  a  limited  loss  of  efficiency.  In  those  cases 
where  the  standard  language  is  inadequate,  the  unusual  usages 
should  be  isolated  in  modules  for  recode. 

Aside  from  subsets  and  extensions,  two  things  in  general  make 
code  difficult  to  transfer  -  techniques  that  bind  to  a  particu¬ 
lar  representation  of  data  structures  and  instructions,  and 
those  that  bind  to  a  particular  sequence  of  operations.  A 
binding  technique,  then,  is  any  usage  that  takes  advantage  of 
or  is  cognizant  of  itself,  when  any  portion  of  any  instruction  is 
used  as  an  operand,  or  when  any  address  is  used  which  is  not 
completely  symbolic.  Code  may  become  cognizant  of  operation 
sequences  because  they  define  a  function  which  must  be  repro¬ 
duced  when  the  program  is  transferred.  In  further  discussions 
in  Section  2,  the  effects  of  these  techniques  will  be  called 
code  restraints. 

Program  code  which  modifies  itself  has  proven  to  be  bad  practice 
for  reasons  of  maintenance  difficulty,  error  proneness,  and  non¬ 
re-entrant  properties.  Recent  machines  and  languages  have  taken 
steps  to  render  self  modifying  code  both  unnecessary  (e.g. 
execute  instructions)  and  difficult  or  impossible  (e.g.  write 
protect) .  Higher  level  language  code  does  not  directly  allow 
dependencies  upon  instruction  representation. 

Generally,  unless  the  machine  is  deficient  in  indexing  and  other 
dynamic  address  functions,  representation-dependent  code  may  be 
easily  avoided.  Furthermore,  resource  conservation  realized 
through  use  of  this  type  of  code  usually  amounts  to  only  an 
insignificant  percentage. 

For  any  particular  machine,  external  data  representations  cor¬ 
respond  to  predictable  internal  storage  bit  patterns.  It  is 
seldom  the  case  that  those  representations  will  be  equivalent 
over  a  variety  of  different  machines.  If  the  external  repre¬ 
sentation  used  does  not  correspond  to  the  function  of  the  item, 
the  internal  representation  will  become  inappropriate  upon 
transfer.  An  example  of  this  type  of  code  is  character  identi¬ 
fication  by  comparison  with  small  decimal  integers. 
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Similarly,  packing  several  data  items  in  a  word  will  bind  the 
code  with  respect  to  word  size,  as  a  data  item  may  be  split  by 
a  word  boundary  upon  transfer.  For  example,  3  items  of  6  bits 
each  do  not  repack  well  into  a  16  bit  word. 

Operation  sequence  and  data  representation  constraints  can 
also  be  combined  in  ways  which  may  seem  of  great  value  but 
which  definitely  hinder  transferability. 

It  is  often  the  case  that  an  assembly  or  higher  level  language 
does  not  explicitly  provide  a  facility  needed  for  a  particular 
application.  The  facilities  that  are  provided  can  be  used  in 
combination  to  synthesize  the  required  facility. 

Such  synthetic  facilities  become  of  transferability  interest  in 
several  ways.  It  may  be  that  one  of  the  facilities  used  in  the 
synthesis  is  not  present  in  the  transfer  target.  Or,  it  may 
be  that  the  corresponding  combination  of  facilities  on  the 
new  machine  does  not  have  the  same  effect.  (In  this  case  the 
original  synthesis  is  called  idiomatic.)  On  one  machine, 
for  instance,  a  fixed  point  number  can  be  converted  to  floating 
point  by  adding  and  subtracting  special  floating  point  constants. 
The  technique  is  very  convenient  and  very  machine  dependent. 


In  any  case,  converting  a  synthetic  facility  component-wise  can 
be  less  efficient  than  finding  or  synthesizing  the  equivalent 
facility  in  the  target  machine  or  system.  Nearly  all  machines 
provide  some  form  of  shift  instruction  for  use  in  synthesizing 
facilities  (usually  bit-resolution  or  data  addressing).  Arithmetic 
and  logical  operations  are  defined  and  stabilized  by  widespread 
usage,  but  the  shift  concept  is  rather  computer  unique  and  is 
usually  defined  at  the  convenience  of  the  computer  architect. 

As  a  result  the  shift  instruction  set  is  often  a  transfer 
problem. 

The  difficulty  of  transferring  synthetic  facilities  may  be 
reduced  by  use  of  macros  in  assembly  language.  The  macro  invo¬ 
cation  statement  becomes  equivalent  to  the  use  of  an  explicit 
rather  than  synthetic  facility.  The  facility  may  be  transferred 
by  using  a  new  synthesis  or,  if  present,  the  explicit  facility, 
in  the  macro  definition.  Fortunately,  the  number  of  facilities 
that  need  to  be  synthesized  is  less  than  the  totality  of  all 
useful  macros. 

The  principles  described  for  modularity  and  parameterization 
applies  as  well  to  the  synthetic  facilities. 
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1.3.5  System  Configuration  Constraints 


A  program  may  be  dependent  upon  aspects  of  system  configuration 
in  ways  that  make  it  infeasible  to  transfer  the  program  to  a 
system  in  which  those  aspects  differ  significantly. 

Those  system  attributes  which  become  severe  constraints  are 
usually  either  system  resources  which  are  heavily  used  or  de¬ 
vices  which  provide  facilities  not  qualitatively  present  on  the 
new  system. 

Primary  storage  is  likely  to  be  the  constraint  most  often  felt. 

If  a  program  is  written  for  a  machine  with  a  large  amount  of 
core  storage,  it  may  be  infeasible  to  move  to  a  machine  with  less 
storage  unless  the  program  was  initially  written  with  this  in 
mind.  Similarly,  programs  often  do  not  adjust  well  to  an  over¬ 
lay/nonoverlay  transition  since  basic  algorithms  may  differ 
(overlay  processing  often  requires  a  file  pass  for  each  phase, 
where  this  would  be  unnecessary  with  adequate  primary  storage). 

On  the  other  hand,  large  primary  storage  may  have  been  crucial 
to  efficient  operation  of  the  program,  and  it  would  be  wasteful 
not  t-'  use  it. 

One  approach  to  this  problem,  then,  is  to  consider  (and  document) 
primary  storage  size  as  a  system  constraint  precluding  code  and 
perhaps  design  for  transfer  to  a  machine  with  less  storage. 

Similar  considerations  apply  to  random  vs  sequential  access 
secondary  storage  devices. 

In  the  area  of  input/output,  efforts  must  be  directed  toward 
avoidance  of  explicit  references  to  physical  devices  which  can 
permanently  bind  a  program  to  a  particular  configuration.  Pro¬ 
grammers  should  design  and  code  with  logical  entities  such  as 
the  system  input  device  (rather  than  the  card  reader)  or  the 
object  output  file  (rather  than  the  tape  punch) .  Physical  de¬ 
vices  and  their  associated  characteristics  (such  as  record 
length)  must  be  parameterized  and  isolated  from  the  main  body 
of  the  program  as  much  as  possible. 

Even  stronger  constraints  apply  to  programs  which  are  intended 
to  exploit  particular  system  aspects.  It  would  be  pointless, 
for  instance,  to  transfer  a  graphics  processor  to  a  system 
without  graphic  I/O  capability.  This  type  of  constraint  can 
be  considered  (and  documented)  as  categorically  apart  from 
others.  In  this  case,  no  partial  loss  of  inefficiency  can 
eliminate  the  constraint. 


1.3.6  Transferability  Feasibility  Analysis 

In  some  cases  it  is  not  immediately  clear  whether  program  trans¬ 
fer  will  be  cost  effective.  Hence,  it  is  desirable  to  compare 
potential  new  machines  with  respect  to  their  suitability  for 
transfer  of  the  existing  library.  A  guide  to  making  such  deci¬ 
sions  must  take  into  account  the  cost  of  the  machine  and  its 
effectiveness  for  running  the  transferred  library. 

If  it  is  assumed  that  the  system  configuration  constraints  are 
met,  and  that  an  acceptable  transfer  method  must  be  available 
(or  at  least  is  well  enough  specified  for  estimating  purposes) , 
then  the  cost  to  be  dealt  with  becomes  the  operating  cost  of 
the  transferred  program.  This  in  turn  depends  on  the  cost  of 
the  resources  provided  by  the  system  and  the  burden  that  the 
program  places  on  those  resources. 

The  resources  treated  here  are  time,  primary  storage  space,  and 
peripheral  device  utilization. 

The  total  operating  cost  is  computed  as: 

Cost  * 

/memory  cost  x  words  +  CPU  cost  +  device  cost  x  devices |  x  secs 
V  word. sec  sec  device. sec  J 

Words,  secs  and  devices  represent  the  space,  time  and  peripheral 
device  support  needed  to  run  the  program.  The  time  and  space 
units  are  arbitrary  -  minutes  or  hours  may  be  more  convenient. 

CPU  cost  includes  all  those  items  without  which  the  system 
cannot  be  used,  including  software. 

Memory  cost  is  treated  separately.  Additional  primary  storac<= 
is  often  optional  or  separately  priced,  and  programs  often  be¬ 
come  larger  upon  transfer. 


The  term 

(  device  cost  x  devices) 
l device. sec  J 

should  be  estimated  for  each  peripheral  device  or  fraction 
thereof  dedicated  to  the  program  and  summed  to  obtain  total 
peripheral  device  costs. 
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When  considering  a  maximum  amount  of  primary  storage  or  a 
maximum  complement  of  peripheral  devices,  the  estimates  can 
be  made  for  the  worst  case  deemed  feasible. 


Effect  of  Transfer  Upon  Size  and  Speed 


Table  IB  in  Section  1.1.3  gives  rough  estimates  of  relative 
operating  costs  by  level  of  transfer  method  (redesign,  recode, 
convert  code)  and  language.  Those  estimates  may  be  revised 
appropriately  for  specific  applications. 


Halstead  (loc.  cit.)  notes  that  assembly  language  programs  in¬ 
creases  in  size  by  as  much  as  30%  upon  code  conversion.  As  a 
first  approximation  it  may  be  assumed  that  the  number  of  inst¬ 
ruction  executions  will  increase  in  the  same  proportion.  Hope¬ 
fully,  programs  that  were  designed  and  coded  with  transfer  in 
mind  will  not  grow  as  radically. 


Estimates  of  higher  level  transferred  code  efficiency  may  be 
refined  by  recording  the  relative  size  and  speed  figures  of 
benchmark  programs  run  fcr  a  new  machine. 

Similarly,  assembly  language  code  may  be  estimated  from  know¬ 
ledge  of  conversion  equivalents.  An  assembler  which  tabulates 
instruction  usage  counts  is  very  helpful  in  this  respect.  For 
instance,  if  linear  instructions  are  converted  to  loops,  in¬ 
struction  execution  counts  will  increase  more  than  proportion¬ 
ately  to  the  code  size  decrease. 
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1.4  GENERAL  PROGRAM  DOCUMENTATION  GUIDELINES 

1.4.1  Introduction 

In  most  cases,  conventional  program  documentation  will  require 
certain  additions  and  changes  to  facilitate  program  transfer. 
This  section  describes  the  additional  documentation  by  purpose, 
information  content,  and  utilization. 

This  additional  information  is  to  be  distributed  over  and  incor 
porated  in  existing  standard  installation  documentation  formats 
A  completely  new  style  might  not  be  suitable  in  some  circum¬ 
stances.  Particular  sections,  such  as  those  for  FORTRAN  or 
JOVIAL  programs,  will  contain  comprehensive  suggestions  as  to 
the  content  of  the  documentation.  They  will  be  especially  im¬ 
portant  in  regard  to  identifying  system  dependencies. 

1.4.2  General  Format 

Documentation  efforts  toward  more  transferable  programs  can  be 
divided  into  four  parts: 

•  Independent  aspects:  These  are  descriptioxis  that  do 
not  change  when  the  program  is  transferred*  This 
includes  the  purpose  and  overall  functioning  of  the 
program  as  well  as  any  details  that  are  clearly 
machine/system  independent. 

•  Program  dependencies:  This  section  covers  those 
things  that  may  change  from  one  machine/system  to 
another.  In  other  words,  it  will  describe  how  the 
program  is  machine  dependent.  This  information  will 
be  used  by  the  programmer  in  determining  what  form 
these  aspects  will  take  in  future  machines  and 
systems. 

•  Specific  implementation:  This  should  describe  the 
form  taken  by  dependent  aspects  for  a  particular 
machine/system.  The  specific  environment  should  be 
clearly  identified. 

•  Transfer  plan:  This  section  describes  the  intended 
method  of  transfer  for  a  program  and  a  particular 
implementation.  Note  that  several  specific  imple¬ 
mentations  of  a  program  may  not  be  equally  trans¬ 
ferable  to  a  new  machine.  The  transfer  plan  should 
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be  specific  as  to  which  version  of  the  program  is 
expected  to  be  transferred. 

Among  the  sections  described  above,  those  dealing  with  indepen¬ 
dent  aspects  and  program  dependencies  can  theoretically  be 
written  once  and  then  remain  valid  for  all  specific  implementa¬ 
tions.  In  practice,  aspects  thought  to  be  independent  may  be 
found  to  be  dependencies  when  the  actual  transfer  is  attempted. 
Specific  implementation  material,  however,  will  clearly  need 
CO  be  re-written  for  each  new  version.  Similarly,  tne  trans¬ 
fer  plan  may  be  partly  specific  to  a  particular  implementation. 

Depending  on  the  volume  of  documentation  required,  the  number  of 
dependencies  involved,  the  frequency  of  transfers,  and  similar 
factors,  several  physical  formats  may  be  used.  Perhaps  the 
most  widely  acceptable  and  convenient,  however,  would  be  the 
current  installation  standard.  As  necessary,  each  paragraph 
could  be  divided  into  independent,  dependent  and  transfer  plan 
subparagraphs.  The  specific  implementation  material  most 
logically  would  appear  in  an  appendix. 

If  the  documentation  is  updated  after  all  projected  transfers 
are  completed,  tne  specific  implementation  material  could  be 
listed  at  the  appropriate  place  in  the  main  text,  with  each 
item  identified  as  to  pertinent  implementation. 

1.4.3  Additions  to  Conventional  Documents 

The  following  paragraphs  review  the  usual  organization  of  pro¬ 
gram  documentation.  Each  level  and  type  of  document  is  identi¬ 
fied  by  purpose  :  nd  customary  content,  and  additional  trails- 
feraoility  information  appropriate  to  each  type  is  described. 

Overview/Introduction 

This  section  should  satisfy  the  needs  of  persons,  typically  in 
management,  who  need  not  become  involved  in  the  details  of  the 
program.  These  individuals  may,  however,  need  to  review  this 
material  with  regard  to  future  efforts  in  the  application  area, 
cost  prediccions,  proposals  and  similar  management  activities. 

This  documentatic-  usually  includes  identification  of  a  program 
by  name,  purpose,  and  position  in  a  larger  system.  It  should 
also  contain: 

•  A  description  of  capabilities  which  are  system- 
independent  . 
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•  System  configuration  constraints. 

t>  A  description  of  optional,  system  dependent 
capabilities . 

•  A  description  of  the  expected  transfer  methods  with, 
at  least,  relative  transfer  cost  estimates. 

•  A  description  of  the  relative  importance  of  the  pro¬ 
gram  to  an  overall  system. 

This  additional  information  may  be  used  to  estimate  the  feasi¬ 
bility  of  transferring  to  various  new  systems. 

Product  or  Functional  Specifications 

This  portion  of  the  documentation  specifies  in  detail  what  the 
program  does.  It  should  also  include  any  aspects  of  the  program 
not  covered  in  the  introduction  but  that  may  be  of  interest  to 
users  and  management..  In  particular,  the  following  transfer- 
ability  information  should  be  added: 

•  System  configuration  constraints. 

•  The  relative  independence  or  dependence  of  each 
program  function-application. 

•  The  nature  of  all  system  dependencies. 

•  The  degree  of  effort  directed  toward  transferability. 

•  Projected  transfers  and  methods  of  transfer. 

•  The  proportion  in  which  total  transfer  effort  is 
divided  between  intial  development  and  actual 
transfer  time. 

Design  Specification  -  Internal  or  Program  Logic  Manual 

This  portion  of  the  documentation  describes  in  complete  detail 
how  the  program  works.  It  includes  narratives,  flowcharts  and 
program  listings.  It  is  a  working  document,  successive  elabora¬ 
tions  of  which  result  in  the  finished  program.  Also,  it  func¬ 
tions  as  a  training  aid  to  the  maintenance/transfer  programmers 
who  may  be  required  to  become  as  familiar  with  the  program  as 
its  authors  were  originally. 
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The  following  paragraphs  describe  the  usual  organization  of  the 
document  along  with  the  extra  material  required  for  transfer- 
ability. 


The  design/logic  document  is  usually  replicated  heirarchically . 
That  is,  there  is  a  section  for  the  program  as  a  whole  and 
similar  sections  for  each  component  subroutine.  These  include 
narrative,  flowcharts,  and  for  some  sections,  listings. 


It  must  be  kept  in  mind  that  the  design/logic  section  is  a  work¬ 
ing  document  rather  than  simply  an  archival  record  of  a  completed 
design.  The  process  of  writing  the  first  draft  of  this  docu¬ 
ment  is  the  process  of  design  of  the  program.  Difficulties 
encountered  in  describing  the  transferability  considerations 
for  a  program  or  subroutine  in  this  section  should  be  taken  as 
a  warning  of  similar  difficulties  to  be  experienced  in  actual 
transfer  of  the  program  or  subroutine. 


The  narrative  included  in  design  specifications  generally  con¬ 
tains  information  such  as: 


© 


Purpose  of  program/subroutine. 


Role  of  this  routine  in  the  program  or  system  and 
entry/exit  details. 


Data  handled  by  this  routine  and  the  input/output 
details . 


Parameters  required/generated. 
Tables  built  or  used. 


The  narrative  continues  with  a  detailed  description  of  the 
algorithms  by  which  the  primary  function  and  subsidiary  func¬ 
tions  are  performed. 


The  flowchart  should  be  a  pictorial  representation  of  the  narra¬ 
tive  (rather  than  of  the  listing).  For  the  program  as  a  whole, 
most  of  the  flowchart  boxes  will  be  subroutines.  Each  box 
should  indicate,  by  subroutine  name  or  listing  label/line  num¬ 
ber,  where  detailed  information  may  be  found. 


Transferability  Information 


Section  1.4.2  recommends  breaking  documentation  into  four 
subsections:  machine  independent  section,  dependency  section. 
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particular  implementation  and  transfer  plan-  For  a  properly 
designed  program,  the  machine  independent  section  will  be  as 
similar  and  complete  as  ordinary  documentation.  In  particular, 
if  some  function  cannot  be  properly  documented  in  the  machine 
independent  narrative,  then  the  design  should  be  modified.  If 
that  is  not  possible,  a  configuration  constraint  is  indicated. 

Items  in  the  machine  independent  writeup  for  which  transfer- 
ability  is  a  consideration  should  be  flagged.  Ordinary  textual 
cross  reference  conventions  are  suitable  for  this;  parenthesized 
note  numbers  are  suggested. 

The  note  numbers  can  then  be  used  in  the  dependency,  particular 
implementation,  and  transfer  plan  subsections  to  relate  items. 

The  scheme  outlined  above  is  used  for  the  program  as  a  whole, 
and  for  each  subprogram.  Key  information  should  be  repeated  in 
the  introduction  to  each  subroutine;  in  particular,  a  subroutine 
which  constitutes  a  machine  independent  module  should  be  so 
identified  in  the  introduction  to  that  subroutine. 

The  following  example  shows  the  mode  of  expression  in  each  of 
the  subsections: 

•  Machine  independent  writeup: 

...the  subroutine  then  finds  the  leftmost  comma  in 
the  character  string  (5)  and  returns  the  next  four 
characters . . . 

•  Dependency  writeup: 

(5)  The  speed  of  the  program  depends  heavily  upon  the 
speed  of  this  search  -  a  basic  assembly  subroutine 
is  indicated. 

•  Particular  Implementation  for  IBM  S/360 

(5)  Translate  and  test  instruction  is  used, 
c  Transfer  Plan 

(5)  Since  the  speed  of  the  transferred  program  is  an 
expected  problem,  manual  rewrite  of  the  code  para¬ 
graph  labeled  SEARCH  in  subroutine  CHARSEL  is 
anticipated  for  minimum  execution  time.. 
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Flowcharts 


The  scale  and  information  content  of  a  proper  flowchart  should 
be  such  that  the  chart  parallels  the  machine  independent  narra¬ 
tive.  A  flowchart  more  closely  related  to  the  code  than  to  the 
narrative  does  little  to  bridge  the  intelligibility  gap  between 
narrative  and  code,  and  is  more  susceptible  to  change  during 
program  debug,  maintenance  and  transfer. 

Listings 

The  document  should  be  organized  and  annotated  so  that  it  is 
easy  to  find  code  lines  corresponding  to  flowchart  blocks  or 
narrative  sentences. 

Code  lines  may  well  be  broken  into  logical  'paragraphs’  by  use 
of  comment  lines.  Any  line  or  'paragraph'  that  is  machine/ 
system  dependent  should  have  comments  explicating  the  dependency 
and  detailing  the  transfer  plan.  Occasionally,  alternative  code 
exists  which  would  be  more  transferable  but  which  is  for  some 
reason  not  justified  in  this  particular  implementation.  Such 
code  may  be  displayed  as  comments,  in  the  appropriate  location. 

Code  of  particular  interest  at  transfer  (or  maintenance)  time 
should  be  indicated  by  comment  lines  having  scan  value,  i.e. 
readily  seen  when  leafing  through  the  listing. 

Manuals 

Usually,  a  separate  document  is  prepared  for  the  guidance  of 
personnel  operating  the  computer  while  the  program  is  being  run. 
It  details  the  input,  intermediate  and  output  files  by  physical 
characteristic,  source,  disposition,  and  the  operating  system 
information  requirements.  It  also  lists  error  and  exception 
conditions,  and  the  dialogs  between  operator  and  operating 
system. 

The  machine/system  independent  portion  of  the  document  serves 
as  an  introduction  to  the  functional  purpose  of  operator  actions 
and  information  responses. 

Since  a  machine-independent  operating  system  cannot  be  assumed, 
it  is  expected  that  the  operator  interface  will  be  very  machine- 
dependent.  Thus,  a  dependency  writeup  would  be  limited  then  to 
a  description  of  the  operational  differences  of  various  systems 
among  which  regular  transfers  actually  take  place.  That  is, 
if  the  program  is  to  be  run  interchangeably  on  several  levels 
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or  versions  of  ostensibly  the  same  machine/system,  the  depend¬ 
ency  writeup  may  detail  the  differences  which  affect  the  opera¬ 
tion  of  the  program.  Additionally,  the  manual  should  include 
detailed  writeups  for  the  particular  system (s)  on  which  the 
program  is  run  regularly. 

The  transfer  plan  portion  should  describe  the  mutual  program/ 
system/operator  interface.  This  is  best  done  in  functional 
terms  such  that  operating  procedures  and  job  control  language 
statements  can  be  designed  for  a  new  system. 

To  avoid  confusing  operators,  the  individual  machine  require¬ 
ments  and  the  transfer  plan  should  probably  be  bound  separately. 

A  user  oriented  manual  must  also  be  prepared.  It  will  be  clear 
from  the  nature  of  the  program  whether  or  not  the  users  will  be 
professional  programmers.  In  any  case,  the  document  should  be 
complete  enough  for  use  by  a  stranger  to  the  program. 

The  machine  independent  part  of  this  document  will  include  all 
facilities  expected  to  be  transferred.  Functional  terms  should 

again  be  used  in  descriptions. 

/ 

The  dependency  section  must  allow  the  user  to  foresee  problems 
that  may  be  encountered  with  particular  features  if  the  program 
is  transferred.  It  is  not  intended  that  the  user  resolve  or  be 
responsible  for  program  transfer.  He  is  entitled,  however,  to 
an  understanding  of  the  status  of  the  program  with  respect  to 
the  risks  or  delays  that  may  be  associated  with  its  use. 

The  particular  implementation  section  should  fully  describe  all 
system  dependent  items,  especially  the  actual  data  formats  and 
conversational  terminal  protocols. 

The  transfer  plan  should  describe  in  detail  whether  and  how  the 
user  will  be  able  to  move  his  data  files  to  a  new  system  if 
necessary . 

The  recommended  documentation  plan,  therefore,  involves  addi¬ 
tions  to  current  installation  standards  rather  than  major 
revisions  to  existing  techniques.  In  this  way,  the  amount  of 
emphasis  placed  on  transferability  can  vary  not  only  by  installa 
tion,  but  also  by  program. 
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1.5  OTHER  TRANSFERABILITY  TECHNOLOGIES 


This  section  touches  upon  several  subjects  which  are  related 
to  transferability  but  which  are  either  of  less  general  applic¬ 
ability  or  are  covered  elsewhere  in  the  literature. 


1.5.1  Microprogramminc 


A  microprogram  is  a  program  to  be  executed  by  a  rather  simple 
computer  for  the  purpose  of  simulating  a  more  powerful  computer, 
which  in  turn  executes  application  programs.  The  hardware  need 
only  interpret  and  facilitate  the  micro  instructions  which  are 
constrained  for  ease  of  execution  rather  than  the  ordinary  non¬ 
micro  instructions  which  are  designed  for  the  convenient 
expression  of  application  algorithms.  Often,  as  with  the  IBM 
360,  the  user  may  not  even  be  aware  that  the  machine  is  micro¬ 
programmed  . 


Microprogramming  has  never  accounted  for  a  very  significant 
percentage  of  total  programming  efforts.  The  percentage  does 
appear  to  be  on  the  increase  as  a  result  of  emphasis  on  emula¬ 
tion  and  because  of  burgeoning  mini-computer  sales.  Neverthe¬ 
less,  because  of  the  small  percentage  of  total  programming  that 
is  in  this  area,  and  because  of  the  nature  of  microprogramming, 
program  re-write  is  the  most  general  means  of  program  transfer. 


Generally,  micro  level  instructions  are  very  much  oriented  to 
the  particular  machine  that  they  are  a  part  of,  and  consequently 
not  very  amenable  to  being  transferred  to  other  computers.  It 
seems  to  be  the  nature  of  microprogrammed  applications  that  the 
requirement  for  program  transfer  occurs  less  frequently.  Still, 
many  of  the  techniques  applied  to  assembly  code  factors  in  order 
to  attain  portability  will  be  directly  applicable  to  similar 
microprogramming  factors.  Hence,  some  of  the  assembly  level 
conclusions  may  be  applied  to  the  microprogramming  factors. 

Microprogrammed  computers  can  actually  provide  significant 
benefits  in  some  transferability  situations.  These  computers 
normally  have  built-in  facilities  for  readily  combining  their 
basic  instructions  into  more  powerful  instructions.  In  this 
manner,  a  specific  microinstruction  computer  can  be  made  to 
operate  like  certain  other  computers.  When  a  set  of  regular 
assembly  level  programs  are  to  be  transferred  to  a  microinstruc¬ 
tion  computer,  this  approach  may  be  feasible.  Often  though, 
the  creation  of  a  correct  emulator  in  the  micro-computer  can 
itself  be  a  fair  size  task.  Incompatibilities  of  word  and 
character  size,  the  absence  in  the  new  machine  of  internal  data 
paths  and  registers  not  essential  to  its  original  architecture. 
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and  differing  I/O  devices  all  limit  emulation  efficiency.  Simi¬ 
larly,  operator  interface  facilities  such  as  console  switches 
cannot  readily  be  stimulated.  Hence,  microprogrammed  machines 
are  by  no  means  a  panacea  for  transfer  problems. 


1.5.2  Interpretive  Languages 


As  with  microprogramming,  the  total  amount  of  interpretive  pro¬ 
gramming  represents  only  a  small  percentage  of  all  programming 
activities.  On  the  other  hand,  the  employment  of  interpretive 
programming  techniques  seems  to  be  on  the  upswing  as  can  be 
evidenced  by  the  increased  usage  of  BASIC  and  APL,  both. of 
which  are  generally  compiled  and  executed  in  an  interpretive 
manner.  Actually,  in  many  instances  utilization  of  interpretive 
instructions  and  languages  may  provide  the  most  promising 
approach  for  strictly  maximizing  program  transferability. 


An  interpretive  language  is  essentially  a  series  of  subroutine 
calling  sequences,  and  the  interpreter  a  set  of  subroutines. 

One  central  subroutine,  analogous  to  the  instruction  fetch  cir¬ 
cuits,  handles  subroutine  linkage,  selecting  the  next  call  in 
accordance  with  sequence  logic  (usually  a  location  counter) , 
isolating  parameters,  and  branching  to  the  designated  subroutine. 
The  pseudo-machine  code  can  be  quite  compact  and  efficient  sim  ' 
the  addressing  facilities  need  not  be  general  but  can  be 
accurately  tailored  to  the  application. 

The  major  shortcomings  of  programming  with  interpretive  code  is 
that  program  execution  speed  will  always  be  less  on  a  specific 
computer  than  the  equivalent  program  coded  at  the  assembly  level 
by  a  good  programmer.  In  some  cases,  recent  refinements  in 
interpretive  languages  and  interpreters,  in  conjunction  with 
increased  computer  speeds,  have  reduced  the  execution  speed 
difference  to  minor  significance. 

The  major  advantages  of  the  interpretive  approach  are: 

•  Significantly  reduced  program  transfer  costs  for 
programs  or  program  libraries. 

e  Significantly  reduced  core  requirements. 

•  Faster  (than  higher  level  language)  execution 
speed. 

•  Facility  for  inclusion  of  debug  aids  and  measure¬ 
ment  tools. 
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An  attribute  common  to  the  more  successful  interpretive  langu¬ 
ages  is  their  approach  to  memory  design,  usually  referred  to  as 
stack  processing.  The  stack  processing  approach  is  to  have 
those  tables  that  are  of  variable  length  share  the  available 
memory  space.  That  is,  the  tables  are  allocated  initial  start¬ 
ing  locations,  and  as  a  table  touches  another,  the  other  tables 
are  moved  to  make  space.  Tables  in  this  type  of  memory  arrange¬ 
ment  are  called  stacks. 

When  interpretive  techniques  are  used,  the  transferability  bur¬ 
den  is  centralized  with  the  designers  of  the  interpreter  and 
the  interpretive  language.  Usually,  programmers  using  these 
languages  have  the  fewest  restrictions  imposed  by  transferability. 
With  a  well  designed  and  standardized  interpretive  language, 
the  greatest  transferability  imposed  restrictions  on  design  and 
documentation  will  be  in  the  area  of  peripheral  equipment  utili¬ 
zation,  and  even  there  the  effect  will  be  minimized. 

By  carefully  designing  ana  standardizing  the  interpretive  langu¬ 
age,  transferability  of  a  program  library  can  be  accomplished  in 
a  very  small  time  frame.  The  essential  task  required  to  accom¬ 
plish  transfer  of  a  set  of  interpretive  programs  is  the  imple¬ 
mentation  of  the  appropriate  interpreter  for  the  new  computer. 

This  can  require  from  one  man  month  to  a  few  man  years  of  effort, 
depending  upon  the  particular  language.  Generally,  the  effort 
involved  in  creating  an  interpreter  is  only  a  small  fraction  of 
the  effort  of  creating  a  traditional  higher  level  language 
compiler. 

It  should  be  noted  that  many  of  the  guidelines  presented  in 
Section  2.4  may  be  used  for  both  interpretive  language  design 
and  for  interpreter  design.  These  promote  transferability  of 
user  programs,  simplify  creation  of  future  interpreters  for  the 
same  language,  and  reduce  the  deleterious  effects  that  inter¬ 
pretive  operations  have  upon  execution  speed. 

Finally,  many  of  the  problems  associated  with  standardizing 
traditional  higher  level  languages  also  exist  with  interpretive 
languages.  This  is  evidenced  by  all  the  extensions  that  manu¬ 
facturers  have  made  to  BASIC  and  that  virtually  all  APL  imple¬ 
mentations  are  for  a  special  version  of  APL.  Were  these  langu¬ 
age  standards  more  comprehensive  and  acceptable,  the  propaga¬ 
tion  of  variations  of  these  languages  would  probably  be  reduced. 


1.5.3  Conversion  Tools 

The  subject  of  source  to  source  converters  was  discussed  in 
Section  1.1.  The  information  presented  there  substantiated  the 
fact  that  there  is  a  significant  economy  of  scale  in  the  develop¬ 
ment  of  conversion  aids.  The  larger  the  pool  of  programs  to  be 
converted,  the  more  the  converter  costs  can  be  justified. 
Primarily  for  this  reason,  the  number  of  commercial  conversion 
aids  currently  available  is  relatively  small.  Similarly,  the 
enormous  possibilities  of  combinations  of  systems,  machines 
and  languages  dictates  that  no  comprehensive  set  of  conversion 
tools  will  ever  be  developed. 

From  a  transferability  standpoint,  therefore,  automatic  program 
conversion  tools  must  be  considered  expensive,  generally 
unapplicable  and  after-the-fact  techniques  on  which  to  base 
future  programming  efforts.  For  the  programs  that  already  exist, 
however,  there  are  a  number  of  aids  which  may  apply. 


A  special  problem  is  presented  when  the  running  object  program 
is  not  identical  with  currently  maintained  source  decks.  This 
may  result  from  extensive  patching  of  assembled  code  or  dropping, 
misplacing,  or  pirating  from  a  source  deck.  There  are  products 
available  which  will  disassemble  the  object  code  to  produce 
source  statements.  Generally,  they  are  limited  to  very  few  mach¬ 
ines  and  are  not  completely  effective.  Decompilers,  especially, 
would  be  enormously  expensive  if  they  were  to  handle  (efficient¬ 
ly)  all  possible  combinations  of  object  code.  Again,  use  of 
this  type  of  conversion  aid  is  generally  the  result  of  a  lack  of 
planning  for  transferability  in  original  programming  efforts. 


Source  to  Source  Conversion 


A  source-to-source  converter  is  a  program  which  can  identify 
constructs  in  one  source  language  and  build  an  equivalent  con¬ 
struct  in  another  source  langauge,  transcribing  the  pertinent 
parameters.  The  equivalence  is  always  programmer  designed. 

Certain  items  may  not  have  an  equivalent  in  the  other  language, 
or  the  translation  is  too  subtle  or  too  inefficient  to  be  worth 
the  effort  for  developing  converter  capability  for  it.  In  these 
cases,  the  converter  should  flag  the  item  for  programmer  attention. 


Compatibility /Compliance  Monitors 


Higher  level  language  programs  are  transferable  only  to  the 
extent  that  they  do  not  use  language  features  that  are 
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different  or  missing  from  the  compiler  of  the  destination 
machine. 

Programs  are  presently  available  which  inspect  COBOL  source 
code  for  compliance  with  management-selected  restrictions.  By 
restricting  usages  which  are  apt  to  be  incompatible,  manage¬ 
ment  can  reduce  future  transfer  difficulty. 

Such  monitors  can  be  developed  for  any  programming  language.  It 
is  more  efficient,  however,  to  incorporate  these  features  in  the 
original  compilers  which  must  completely  analyze  source  code 
anyway.  The  WATFOR  FORTRAN  compiler  mentioned  elsewhere  is  an 
example  of  this  approach.  Unfortunately,  few  compiler  imple¬ 
mentors  seem  willing  to  admonish  customers  against  the  use  of 
competitively  motivated  language  features. 

Usage  Reference 

The  cross  reference  listing  produced  by  many  assemblers  and  com¬ 
pilers  can  easily  be  made  to  include  information  on  the  use  of 
particular  language  features.  For  example,  the  locations  and 
frequency  of  use  of  instructions  and  addressing  methods  such  as 
indirect  would  be  a  definite  aid  during  program  transfer. 

1.5.4  Language  Standards 

Perhaps  the  most  fundamental  step  toward  transferability  of  pro¬ 
gramming  languages  is  standardization.  This  opinion  is  reflec  - 
ed  by  the  existence  of  standards  committees  such  as  those  of 
ANSI  (American  National  Standards  Institute)  which  have  been 
organized  for  most  popular  languages.  It  has  long  been  recog¬ 
nized  that  substantial  savings  in  programmer  retraining,  manual 
preparation,  and  program  transfer  can  achieved  through 
language  compatibility.  Unfortunately,  there  are  many  problems 
associated  with  this  endeavor.  Among  these  are: 

•  Inability  to  completely  and  clearly  define  the  language 
4  Subsetting 

•  Extensions 

•  Dialects 

•  Enforcement 

Most  of  the  work  in  language  definition  has  been  in  the  area  of 
syntax.  The  semantics  and  practical  usage  descriptions  of  most 
languages  leave  much  room  for  improvement.  There  are  often 
ambigious  and  generalized  statements  which  must  be  interpreted 
by  individual  implementors.  Similarly,  some  groups,  motivated 
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by  efficiency  or  competitive  advantage  considerations  (maybe 
even  ego),  will  seek  to  "improve"  upon  standards  by  making 
changes  to  the  ruies. 

In  other  instances,  hardware  characteristics  such  as  characters 
per  word  may  cause  the  imposition  of  non-standard  conventions 
(such  as  name  size)  for  the  sake  of  operating  efficiency.  This 
may  be  encouraged  by  the  common  contract  agreements  to  process 
a  specified  number  of  cards  pei  minute  or  to  operate  within  a 
given  core  partition,  etc.  This  type  of  alteration  is  usually 
referred  to  as  a  dialect. 

Another  area  where  hardware  plays  an  important  part  is  in  langu¬ 
age  extensions.  Often  the  ability  to  utilize  special  hardware 
such  as  direct  access  devices  can  present  a  considerable  short¬ 
term  competitive  advantage.  Similar  arguments  and  justifica¬ 
tions  can  be  given  for  application  oriented  additions  to  a 
language.  This  form  of  non-standardization  is  not  readily 
controlled  by  the  customer-user. 

Hence,  standards  committees  are  faced  with  the  ambitious  task 
of  concisely  defining  a  language  which  will  exactly  suit  every¬ 
one's  needs.  Of  course,  a  conglomeration  of  all  the  opinions, 
techniques  and  desires  is  not  a  realistic  goal. 

Standards  committee  must  usually  omit  some  useful  language 
features  because  not  all  compiler  implementors  can  afford  them. 
Even  so,  some  features  included  in  the  standard  may  be  left  out 
of  some  implementations  as  too  expensive.  Thus,  subsets  of  a 
language  come  into  existence. 

The  COBOL  standard  seeks  to  resolve  the  subset  problem  by  defin¬ 
ing  standard  subsets  as  well.  Despite  this,  few  COBOL  compilers 
actually  conform  even  to  a  standard  subset.  A  possible  solution 
is  to  define  a  fundamental  minimum  language  with  a  mechanism 
whereby  extensions  may  be  defined. 

Even  if  all  the  individual  requirements  could  be  resolved,  there 
would  still  be  the  problems  of  enforcement.  More  will  be  said 
about  this  aspect  and  the  extent  of  current  non-adherence  to 
established  standards  in  the  sections  on  higher  level  languages. 

1.5.5  Universal  Machines 

The  transferability  problem  could  be  effectively  eliminated  by 
removing  all  the  differences  among  machines,  systems,  and 
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languages.  It  must  be  pointed  out,  however,  that  had  blanket 
standardization  of  hardware  been  adopted  when  it  was  first 
suggested,  the  machines  of  the  1950 's  would  still  be  in  use. 

Computer  architecture  is  still  being  improved.  Some  features 
presently  very  common  are  demonstratably  less  cost  effective 
than  some  newer  developments. 

The  marketplace,  itself,  seems  to  impose  the  optimum  constraint 
upon  architectural  change.  Customer  acceptance  of  a  new  machine 
depends,  in  part,  upon  the  advantages  of  a  new  architecture 
outweighing  the  disadvantage  of  difficult  program  transfer.  As 
program  libraries  grow,  transferability  becomes  more  important 
to  the  users,  and  hardware  changes  are  inhibited  unless  they 
are  clearly  cost  effective. 

Furthermore,  the  ever  growing  variety  of  applications  and  require¬ 
ments  for  computer  systems  will  certainly  continue  to  obviate 
complete  hardware  stagnancy. 

The  concept  of  the  universal  languages  as  related  to  hardware 
differences  is  discussed  in  Section  2.4. 

1.5.6  Operating  Systems 

Operating  system  differences  are  often  the  major  transfer  prob¬ 
lem  when  standard  higher- level  languages  are  used.  The  operating 
system  and  the  language  used  to  control  it  are  usually  more  com¬ 
plex  than  any  other  element  of  the  system.  Further,  there  seems 
to  be  no  constraint  upon  operating  systems  diversity. 

Operating  systems  and  job  control  languages  are  the  subject  of 
a  study  by  Applied  Data  Research  Corporation,  and  the  reader  is 
referred  to  their  report. 

1.5.7  Data  Bases 

A  production  program  usually  represents  a  continuing  process 
with  several  files  read  regularly  and  updated  periodically.  If 
tne  program  is  transferred,  and  the  process  is  to  continue  on 
the  new  system,  the  files  must  be  moved  also.  This  represents 
a  problem  in  several  ways: 

•  The  organization  of  the  data  may  reflect  the  organiza¬ 
tion  of  the  original  machine  and  be  inappropriate  to 
the  new  machine. 
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•  The  hardware  determines  physical  format  of  the  data 
and  thus  incompatibility  with  new  hardware. 

•  The  operating  system  usually  has  certain  conventions 
about  labels,  retrieval  index  formats,  tables  of  con¬ 
tents,  record  sequence,  etc.  Many  of  these  conventions 
are  considered  transparent  to  the  user  and  are  ill- 
documented. 

•  The  structure  of  the  data  may  be  implicit  in  the 
code,  rather  than  explicitly  described.  This  is 
really  a  program  transfer  problem, but  it  can  be 
alleviated  by  some  measures  that  alleviate  the  data 
transfer  difficulties. 

Data  base  considerations  are  covered  in  depth  in  other  reports 
(ADR  Study) . 
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SECTION  2.  P ROGRAMMING  LANGUAGE  GUIDELINES 


This  section  presents  specific  design  guidelines  for  programs 
to  be  implemented  in  the  higher  level  languages  FORTRAN,  JOVIAL 
and  COBOL.  Suggestions  for  assembly  and  macro  language  program 
preparation  are  also  included  in  a  separate  chapter. 

Each  of  the  languages  is  treated  independently.  Once  the  imple¬ 
mentation  language  is  chosen  for  a  particular  program,  the 
appropriate  section  may  be  reviewed  prior  to  actual  design  and 
coding.  In  most  cases,  references  to  other  portions  of  this 
document  will  not  be  necessary. 

The  following  tables  are  referenced  in  the  discussions  of  dia¬ 
lects.  They  represent  a  possible  method  of  assignment  of  costs 
to  the  use  of  language  extensions  versus  adherence  to  recognized 
standards . 


Levels  of  Impact  on  Transferability-Rework 
_ Necessary  to  Conform  to  Standards 

Tl  -  Readily  available  user  routines  may  be  substituted 
T2  -  Requires  occasional  coding  changes  or  convers ' on  tools 
T3  -  Requires  minor  design  changes  and  re-coding 
T4  -  Requires  extensive  re-coding 
T5  -  Requires  major  re-design 
U  -  Unlikely  to  be  a  problem 

Inconvenience  Costs  of  Adhering  to  the  Standard 

LI  -  Minor  additional  programmer  effort  required 
L2  -  Additional  coding  required 

L3  -  Major  additional  programmer  awaren  :s/effort 

L4  -  Major  additional  coding  required 

L5  -  May  be  no  substitute  -  management  decision 
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2.1  COBOL  PROGRAMMING  FOR  TRANSFERABILITY 

2.1.1  Introduction 

The  development  of  COBOL  (COmmon  Business  Oriented  Language) 
began  as  -he  result  of  a  desire  for  a  business  oriented  source 
language  that  was  widely  compatible  among  host  computers.  For¬ 
mal  work  started  in  1959  under  the  direction  of  language  experts 
from  several  major  computer  manufacturers.  Maintenance  ana 
organized  changes  to  COBOL  have  since  become  the  responsibility 
of  a  group  called  CODASYL  (Conference  on  Data  Systems  Languages) . 
The  most  significant  aspect  of  this  history  is  that  the  original 
design  committee  was  composed  of  representatives  from  competing 
manufacturers  who  were  attempting  to  create  a  language  usable 
on  many  unrelated  computers. 

Achieving  maximum  compatibility  on  existing  equipment  has  always 
been  the  goal  of  COBOL  development.  Application  areas  were  in¬ 
tended  to  be  confined  to  business  data  processing  with  no 
attempt  to  generalize  the  capabilities,  though  some  implementa¬ 
tions  are  tending  toward  expansion  of  scientific  programming 
features . 

COBOL  users  can  encompass  a  wide  spectrum  of  individuals.  The 
relatively  inexperienced  programmer  would  enjoy  the  naturalness 
of  COBOL,  while  the  supervisor  or  business  manager  would  find 
that  the  inherent  readability  of  programs  provides  very  adequate 
documentation.  The  machine  level  programmer,  as  a  matter  of 
fact,  might  be  unhappy  with  the  verbosity  required;  however,  the 
ability  to  document  programs  while  composing  them  and  to  under¬ 
stand  what  has  been  done  when  the/  are  completed  certainly  is  an 
asset  to  later  machine  transfer  and  re-coding. 

COBOL  is  divided  into  four  parts:  IDENTIFICATION,  ENVIRONMENT, 
DATA,  and  PROCEDURE  DIVISIONS.  The  IDENTIFICATION  DIVISION  is 
really  self-explanatory  and  for  the  most  part  transferable 
across  many  compilers.  The  ENVIRONMENT  DIVISION  is  intended 
to  be  the  focal  point  of  thr.  machine  dependent  qualities  in 
COBOL  programs.  Thus,  an  attempt  is  made  within  the  language 
to  isolate  compatibility  problems.  The  DATA  DIVISION,  which 
describes  records,  files,  and  program  data,  experiences  the  most 
difficulty  in  system  transfer.  It  is  in  this  area  that  exten¬ 
sions,  interpretations  and  more  subtle  compiler  dependencies 
are  concentrated.  The  PROCEDURE  DIVISION,  which  handles  the 
bulk  or  problem  program  execution,  can  be  made  relatively  mobile 
if  care  is  taken  to  parameterize  implementation  dependent 
ettributes  via  the  ocher  divisions. 
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As  with  all  languages,  compatibility  problems  do  exist  in  COBOL. 
The  following  sections  will  try  to  point  some  of  the  ways  in 
which  tnese  difficulties  can  be  minimized. 

2.1.2  Dialects 

The  first  formal  definition  of  COBOL  was  released  in  I960.  That 
version  is  now  referred  to  as  COBOL--60.  Subsequent  versions  are 
called  COBOL-61,  COBOL-62,  etc.  The  ANSI  standard  COBOL  des¬ 
cription  used  m  this  document  was  published  in  1968  and  shall 
hereafter  be  referenced  as  "the  Standard". 

As  in  most  modern  languages,  COBOL  does  not  remain  unchanged. 

Some  aspects  become  obsolete  while  others  are  augmented  with 
new  words,  clauses  and  usages.  Often  this  evolutionary  process 
results  in  several  ways  of  doing  the  same  thing.  Since  too 
much  flexibility  creates  confusion  and  increases  the  burden  of 
new  compiler  implementation  and  testing,  many  COBOL  users  have 
adopted  subsets.  Software  products  such  as  MECCA  360  have  been 
developed  to  precompile  programs  and  enforce  this  type  of 
restriction.  In  an  attempt  to  control  and  clarify  this  trend, 
the  Standard  has  adopted  the  following  elementary  terminology 
which  allows  for  three  levels  of  capabilities.  Specific  func¬ 
tions  within  COBOL  are  referred  to  as  modules.  A  particular 
module  can  attain  one  of  three  levels.  0  indicates  no  capa¬ 
bility.  In  the  following  table,  n  represents  the  level  supported 
by  a  particular  compiler. 


Module 

Specific 

Implementation 

Level 

Range 

Nucleus 

n 

NUC 

1,2 

1-2 

Table  Handling 

n 

TBL 

1,3 

1-3 

Sequential  Access 

n 

SEQ 

1,2 

1-2 

Random  Access 

r. 

RAC 

0,2 

0-2 

Sort 

n 

SRT 

0,2 

0-2 

Report  Writer 

u 

RPW 

0,2 

0-2 

Segmentation 

n 

SEG 

0,2 

0-2 

Library 

n 

LIB 

0,2 

0-2 

The  full  standard  involves  complete  implementation  of  all 
modules.  The  Air  Force  has  defined  subsets  A,  B  and  C  as 
follows : 
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Tset  Desert  ption 


A  1  NLC,  1  TBL ,  I  SEQ 

B  2  NUC,  2  TBL,  2  SEQ,  2  RAC,  i  SEG,  1  LIB 

C  2  NUC,  2  TBL,  2  SEQ,  2  RAC,  1  SRT ,  2  RPW,  1  SEG, 

1  LIB 

Basic  differences  between  module  levels  is  summarized  in  this 
table : 

1  NUC  Basic  math  operators  such  as  ADD  and  SUBTRACT 

2  NUC  COMPUTE  verb,  options  to  internal  verbs  such  as 

ROUNDED,  and  DATA  DIVISION  enhancements  such  as 
level  66  in  PICTURE 

1  TBL  One  level  subscripting 

2  TBL  Three  level  subscripting 

3  TBL  SEARCH,  SET,  KEY,  ASCENDING/DESCENDING,  INDEXED  BY 

1  SEQ  Basic  file  processing 

2  SEQ  Control  of  storage  allocation  and  file  labels 

1  SRT  Linkage  to  generalized  sort  program  and  access 

to  records  before  and  after  sorting 

2  SRT  Multiple  sorts 

1  SEG  Overlays 

2  SEG  Variable  limit  assignments 

1  LIB  COPY 

2  LIB  COPY  REPLACING 

Random  access  and  report  writing  seem  self-explanatory;  they 
are  either  full  implementation  or  null.  By  this  time  nearly 
all  major  manufacturers  have  implemented  at  least  Subset  B  on 
large  scale  machines. 

There  are  also  many  factors  which  contribute  to  extensions  of 
the  COBOL  standard.  Disk  files  and  random  access,  a  desire  for 
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more  computational  ability  via  floating  point  number  represent¬ 
ations  and  built-in  functions,  international  currency  considera¬ 
tions,  debug  aids,  buffer  allocation  control,  differences  in 
collating  sequences,  a  desire  to  abbreviate,  flags  to  the  sys¬ 
tem,  and  modularity  in  subroutine  compilation  are  examples  of 
such  influences. 

As  mentioned  elsewhere ,  the  use  of  extended  capabilities  can  be 
severely  detrimental  to  program  transferability.  The  prime 
uniformity  which  exists  among  these  "improved"  versions  is  their 
choice  of  unique  names  and  methods  of  implementation.  In  other 
words,  an  extended  COBOL  compiler  can  not  guarantee  that  ail 
other  augmented  implementations  will  be  compatible.  Clearly, 
many  features  which  are  quite  useful  for  a  specific  application 
or  facility  must  be  discarded  if  program  and  programmer  porta¬ 
bility  are  to  be  maintained. 

The  orderly  updating  of  the  Standard  and  adherence  to  current 
Standard  features  (which  hopefully  will  become  subsets  of  tie 
the  improved  Standard)  is  strongly  recommended. 

In  the  meantime,  several  large  scale  computers  maintain  highly 
extended  COBOL  compilers.  ‘The  following  charts  attempt  to 
present  some  of  the  more  obvious  deviations  from  the  Standard. 
The  COBOL  compilers  referenced  (IBM  360,  CDC  6600,  UNIVAC  1108, 
Burroughs  B5500)  are  all  medium  to  large  scale.  Refer  to  the 
introduction  to  Section  2  for  an  explanation  of  the  transfer- 
ability  and  avoidance  cost  symbols. 
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STANDARD  DIALECT  DEVIATIONS  CHART 
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A  secondary  result  of  extensions  to  a  language  is  the  prolifera¬ 
tion  of  compiler  reserved  words.  Even  though  a  program  may  be 
coded  in  strict  adherence  to  the  Standard,  it  may  produce  errors 
when  run  on  another  system  if  programmer  defined  names  conflict 
with  the  new  compiler's  extensions.  An  attempt  to  delineate  all 
possible  reserved  words  seems  unreasonable.  The  following  par¬ 
tial  list,  however,  may  give  the  COBOL  programmer  some  insight 
into  name  formation  techniques  to  avoid.  In  particular,  the 
avoidance  of  expansions  or  abbreviations  of  standard  reserved 
words  is  a  good  practice. 
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Extended  List  of  COBOL 
Reserved  Words  (Non-Standard) 


ABOUT 

DIRECT-ACCESS 

ABS 

DISK 

AN 

DISPLAY-ST 

APPLY 

DIV 

ARCTAN 

DOLLAR 

DRUM  (S ) 

B-5500 

DUMP 

BEGINNING 

BEGINNING-FILE-LABEL 

EDITION-NUMBER 

BEGINNING-TAPE-LABEL 

END-OF-FILE 

BINARY 

END-OF-JOB 

BIT  (S ) 

END-OF-TAPE 

BLOCK-COUNT 

EQ 

BLOCKS 

EXCEEDS 

BOTTOM 

EXECUTE 

BOTTOM-OF-PAGE 

EXHIBIT 

BZ 

EXITING 

EXP 

CALL 

EXPONENTIATED 

CARD-PUNCH 

EXTENDED 

CARD- READER 

CHANGED 

FAST RAN 

CHANNEL 

FORMAT 

CHECK 

FORM-OVERFLOW 

CL 

FORTRAN 

CLASS 

FS 

CLUSTER-DUMP 

CMP 

GQ 

CONSOLE 

GR 

CONSTANT 

GREATER- EQUAL 

CONVERSION 

COS 

HYPER 

CP 

CREATION- DATE 

IBM-360 

CYCLE 

INCLUDE 

INTERNA! 

DEBUGG 

DECIMAL 

JS 

DEMAND 

DENSITY 

KEYBOARD 

DESTRUCTIVE 

DIAGNOSTIC-FILE 

LEAVING 

DIGIT (S) 

LESS-EQUAL 

DIRECT 

LIBRARY 
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Extended  List  of  COBOL 
Reserved  Words  (Non-Stemdard) 


(Continued) 


LINKAGE 

PRINTER (S) 

LN 

PRINT-SWITCH 

LOAD 

PRIORITY 

LOCATION 

PROTECT 

LOW 

PT 

LOWER- BOUND (S ) 

PUNCH 

LP 

PUNCHB 

LQ 

LS 

PURGE 

RANGE 

MASS-STORAGE 

READY 

MD 

RECORD- COUNT 

MEMORY- DUMP 

RECORDING 

MFID 

RECORD-MARK 

MINUS 

REEL- NUMBER 

MOD 

REFERENCING 

MONITOR 

RELATIVE 

MULTIPLIED 

RENAMING 

RESTRICTED 

NAMED 

RETENTION 

NGR 

REWRITE 

NLS 

NQ 

RG 

SAVE- FACTOR 

OC 

SENTINEL 

OH 

SEQUENCED 

ORGANIZATION 

SIN 

OTHERWISE 

SN 

OV 

SORT-FILE 

OVERFLOW 

SPACING 

SQRT 

PAD 

STANDBY 

PAP  ER-TAPE-PUNCK 

SUBROUTINE 

PAPER-TAPE- READER 

SUPERVISOR 

PC  \ 

SUPPRESS 

PER  \ 

SWITCH 

PHYSICAL-TAPE-NUMBER 

SY 

PLACE (S)  l 

SYMBIONT 

PLUS 

SYMBOLIC 

POINT (S) 

SYSIN 

POOL  / 

PREPARED 

SYSOUT 

Extended  List  ot  COBOL 
Reserved  Words  (Non-Standard) 

(Continued) 

SYSPUNCH 

SZ 

TAPE-PUNCH 
TAPE-READER 
TECHNIQUE-A  (Z) 

TEST-PATTERN 

THEN 

TRACE 

TRACK-AREA 

TRACKS 

TRANSFORM 

TRY 

UNEQUAL 
UNISERVO 
UPPER-BOUND (S) 

UTILITY 

WORD 

WRITE-ONLY 

XS3 

ZS 
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2 c 1 . 3  System  Environment 

As  mentioned  earlier,  a  great  deal  of  emphasis  was  placed  on 
machine  independence  in  tne  development  of  COBOL.  Certain  attri¬ 
butes  of  the  operating  environment  will  always  be  unique  how¬ 
ever.  Many  of  these  aspects  that  depend  on  the  physical  char¬ 
acteristics  of  .  specific  system  are  isolated  in  the  ENVIRONMENT 
DIVISION  of  the  COBOL  program. 

Since  it  v.as  intended  to  be  machine-oriented,  a  significant  part 
of  this  division  must  be  re-coded  each  time  a  system  transfer 
(or  configuration  change)  is  made.  The  other  divisions  are  nc 
completely  relieved  of  dependency  problems,  however. 

System  characteristics  do  have  some  effect  on  the  methods  of  data 
description  in  the  DATA  DIVISION.  The  file  description,  for 
example,  contains  references  to  recording  techniques  such  as  tape 
labeling  and  record  and  block  sizes.  Similarly,  the  results  of 
SYNCHRONIZED  clauses  depend  on  boundary  alignment  and  word  organ¬ 
ization  features  of  a  particular  machine. 

To  a  large  extent,  the  PROCEDURE  and  IDENTIFICATION  divisions 
require  little  change  during  system  transfer  provided  that  dia¬ 
lect  extensions  have  been  avoided. 

Perhaps  the  most  troublesome  aspect  of  COBOL  transfers  in  gen¬ 
eral  is  the  input/output  function.  The  SPECIAL  NAMES  clause  of 
the  ENVIRONMENT  DIVISION  can  be  used  to  equate  implementor 
defined  device  mnemonics  to  programmer  defined  names  used  in 
the  PROCEDURE  DIVISION,  but  other  less  obvious  problems  are  not 
so  easily  resolved- 

The  IOCS  (Input/Output  Control  System)  requirements  for  each 
machine  are  unique  and  produce  a  wide  variation  in  record  for¬ 
matting  and  file  organization.  These  differences  may  not  be  of 
concern  to  the  problem  programmer  while  he  is  coding  for  one 
particular  system,  but  they  will  become  apparant  when  transfers 
are  attempted. 

Each  operating  system  has  its  own  unique  file  control  block 
(feb)  to  which  information  is  supplied  by  the  FD  statement  and 
other  sources.  Often  sub-parameters  are  left  null  to  be  filled 
in  by  the  system  at  execution  time.  This  group  of  language 
features  is  therefore  somewhat  system  dependent.  Many  computers 
have  more  than  one  way  to  record  information.  RECORDING  MODE, 
for  instance,  is  mandatory  for  IBM  and  unimplemented  by  UNIVAC. 
DATA  RECORD  and  RECORD  CONTAINS  are  sometimes  ignored  and 
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treated  as  comments  while  other  compilers  check  their  syntax 
even  though  the  clauses  cause  no  specific  action.  In  any  case, 
the  words  used  and  the  physical  effects  generated  are  unique  to 
each  manufacturer. 

An  example  of  a  problem  which  may  arise  is  the  transfer  of  a 
program  written  for  a  word-oriented  computer  to  a  character- 
oriented  machine.  Sometimes,  the  number  of  characters  in  a 
record  need  not  be  a  multiple  of  the  number  of  characters  in  a 
machine  word.  However,  on  many  computers,  the  smallest  unit  that 
can  be  handled  is  a  word.  In  this  case,  if  a  data  entry  does  not 
use  all  the  characters  of  the  last  word  on  a  data  record,  the 
whole  word  is  output.  When  read  back  into  the  same  computer, 
the  extra  characters  are  ignored.  However,  when  the  same  record 
(assuming  constant  density,  blocking,  etc.)  is  read  into  the 
character-oriented  machine,  the  extra  characters  become  the 
start  of  the  next  record.  Hence,  when  a  transfer  is  contemplated, 
it  would  be  wise  to  re-code  the  record  description  to  include  a 
FILLER  ENTRY  to  receive  the  extr^  characters. 

More  serious  conversion  problems  do  exist.  Consider  the  compati¬ 
bility  of  BCD  variable  length  and  multiple  internal  representa¬ 
tion  fixed  word  length  systems.  Clearly,  such  situations  are 
.iard  to  understand  let  alone  resolve.  A  suggested  technique  to 
minimize  these  nightmares  is  to  use  DISPLAY  numerics  (which  are 
the  most  standard)  for  all  files  that  may  experience  machine 
transfer.  If  computational  fields  appear  in  the  program,  they 
must  be  converted  via  a  MOVE  to  an  intermediate  DISPLAY  file 
before  output. 

Because  some  record  formats  may  be  extremely  uncompatible 
(different  character  sizes)  it  may  ne  necessary  to  code  inter¬ 
mediate  assembly  language  utilities. 

The  general  problem  of  input/output  errors  is  best  lo  ~.t  to  the 
system,  but  first  time  read  errors  after  OPEN  should  .  •  con¬ 
sidered  by  the  programmer.  They  are  most  likely  recoix  length 
problems,  and  the  program  should  be  able  to  tell  if  correct 
data  is  present  before  self  or  involuntary  abortion  (this  can 
be  handled  with  DECLARATIVES). 

Another  suggestion  is  to  place  input/output  in  a  SECTION  by  it¬ 
self  and  PERFORM  it.  This  method  is  best  for  ease  of 
maintenance . 


A  list  of  miscellaneous  factors  pertaining  to  the  system 
environment  follows. 
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•  REVERSED  input  is  not  universally  available. 

•  Integer  or  identifier  names  are  preferable  to 
implementor  supplied  mnemonics. 

•  CLOCK-UNITS  differ  from  machine  to  machine. 

•  FILE  LIMITS  are  hardware  dependent. 

•  LABELS  are  implemented  defined. 

•  ACTUAL  KEY  clauses  are  hardware/implementor 
dependent . 

•  DATE  and  TIME  may  be  a  single  word  or  require 
an  input  card. 

•  The  effect  of  OPEN  and  CLOSE  on  internal  operations 
is  determined  by  the  individual  system. 

•  BLOCK,  RECORDING  MODE,  and  RECORD  CONTAINS  vary 
greatly. 

•  Special  characters  <  :•  <  >  and  others  are  not 
implemented  on  many  computers. 

•  Card  column  punches  and  their  internal  representa¬ 
tions  are  not  universal. 

•  Quotation  marks  may  consist  of  either  '  (IBM)  or  " 
(RCA) . 

•  APPLY  may  be  required  for  ail,  some,  or  none  of  the 
files . 

•  Optimization  specifications  (SAME  AREA)  will  differ. 

•  File  identification  within  multi-file  and  multi-reel 
tapes  may  be  a  problem. 

•  The  collating  sequence  may  no  longer  be  valid. 

•  The  precision  available  in  numeric  calculations  may 
no  longer  be  adequate . 

•  Core  space  may  be  less . 
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•  The  number  of  peripherals  available  may  change. 

•  The  printer  line  size  may  be  reduced. 

•  Sense  switches  may  not  exist. 

•  Console  interface  may  not  be  permitted. 

•  STOP  may  not  be  allowed. 

•  Report  headings  should  be  kept  under  120  characters 
or,  if  necessary,  coded  as  120  characters  and  12 
characters  combined. 

2.1.4  Modularity 

COBOL  users  may  justifiably  claim  that  it  is  one  of  the  most 
"modular ly  organized"  higher  level  languages  in  current  use. 

A  survey  of  the  syntax  makes  this  obvious.  The  segregation  of 
many  system  dependent  attributes  to  the  ENVIRONMENT  DIVISION 
and  further  separation  of  hardware  oriented  aspects  of  the  prob¬ 
lem  program  into  DATA  and  PROCEDURE  divisions  is  evidence  of 
this  inherent  modularity. 

Any  programmer  will  testify  to  the  rigidity  of  style  necessary 
to  produce  acceptable  DIVISION,  SECTION,  PICTURE  and  paragraph 
structures.  Though  somewhat  of  a  nuisance  to  the  application 
programmer,  this  division  of  functions  within  a  COBOL  program 
is  a  great  aid  to  clarity,  maintenance  and  overall  portability. 

Although  the  dummy  argument-subroutine  capability  of  FORTRAN 
and  the  desirable  feature  of  modular  compilation  are  not  avail¬ 
able  in  standard  COBOL,  most  business  applications  do  not  seem 
to  suffer  greatly.  The  use  of  the  PERFORM  verb  and  its  attend¬ 
ant  options  allow  for  great  flexibility  of  design.  Many  machine 
dependent  functions  such  as  I/O  may  be  assigned  to  independent 
paragraphs  and  utilized  from  various  points  within  the  program. 

Ihe  principle  example  of  this  technique  would  be  the  isolation  of 
OPEN,  CLOSE,  READ,  WRITE,  ACCEPT,  DISPLAY  and  associated  format 
conversion  routines. 

Other  languages  called  up  via  the  ENTER  directive  should  also  be 
subroutinized  in  this  fashion. 

Also,  some  non-standard  features,  because  of  their  power  and 
ease  of  use,  may  find  their  way  into  a  program.  If  this  is  the 


case,  the  user  should  be  aware  that  special  treatment  will  be 
necessary  at  conversion  time.  This  would  be  greatly  facilitated 
by  the  preparation  of  a  special  area  of  usage  and  a  documentation 
package  entitled  "Non-standard  features  utilized  -  minimum  sub¬ 
set  necessary".  The  chances  are  that  someone  other  than  the 
original  author  will  do  the  conversion. 

Another  area  where  suspected  machine  dependent  items  may  be 
grouped  is  WORKING-STORAGE  (put  these  items  first) .  Even  an  old 
characte-  set/collating  sequence  may  be  entered  here  eventually 
for  data  translation. 

The  COBOL  feature  with  the  greatest  potential  for  alleviating 
transferability  re-work  is  the  COPY  directive.  If  many  pro¬ 
grammers  can  use  standardized  (within  the  installation)  des¬ 
criptions  in  the  ENVIRONMENT  DIVISION,  SPECIAL  NAMES,  FILE 
CONTROL  and  I/O  CONTROL  SECTIONS ,  a  great  deal  of  redundant 
coding  could  be  eliminated.  These  standards  could  be  done  once, 
entered  into  the  library  and  called  via  the  COPY  option.  For 
example, 

FD  PAYROLL-HISTORY  COPY  LIB-01 

would  constitute  a  complete  file  description.  Even  though  some¬ 
times  the  formats  do  not  show  it,  library  calls  may  be  utilized 
by  almost  every  section  of  a  source  program.  PROCEDURE  library 
modules  could  contain  a  majority  of  the  I/O  discussed  earlier. 

A  typical  summary  of  the  forms  of  COPY  available  is  included 
below. 

In  the  Environment  Division : 

COPY  library-name. 

COPY  library-name. 

COPY  library-name. 

COPY  library-name. 

COPY  library-name. 

In  the  File  Section: 

FD  file-name  COPY  library-name. 

SD  sort-file-name  COPY  library-name. 

01  data-name  COPY  library-name. 


SOURCE-COMPUTER. 
OBJECT-COMPUTER. 
SPECIAL- NAMES. 
FILE-CONTROL. 
I-O-CONTROL. 
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In  the  Working-Storage  Section: 


01  data-name 

In  the  Report  Section; 

RD  report-name 
01  data-name 

In  the  Procedure  Division: 


COPY  library-name, 


COPY  library-name. 
COPY  library-name. 


procedure-name 
2.1.5  Parameterization 


COPY  library-name, 


Almost  all  computer  programs  possess  one  common  attribute;  they 
will  require  change.  Modifications  to  design  or  programming 
techniques,  revisions  to  customer  or  application  specifications 
and  hardware/system  transfer  all  contribute  to  this  problem. 
Particularly  susceptible  to  these  events  are  table  sizes,  hard¬ 
ware  device  names,  arithmetic  and  format  literals,  the  structure 
of  files,  printer  control  and  the  scaling  and  precision  of  num¬ 
eric  data. 

Needless  to  say,  it  would  be  extremely  unwise  to  ignore  these 
possibilities.  The  judicious  use  of  compile  time  parameteriza¬ 
tion,  on  the  otherhand,  can  eliminate  much  of  the  individual 
analysis  and  modification  usually  necessary  in  a  system  change. 

COBOL  does  not  contain  an  over  proliferation  of  parameterization 
possibilities,  but  the  careful  programmer  can  produce  a  more 
transferable  product  if  he  makes  full  use  of  what  is  available. 

The  following  list  should  be  considered  (and  augmented)  before 
beginning  a  new  program. 

©  Define  all  literals  that  are  used  often  in  the 
PROCEDURE  code  in  the  WORKING- STORAGE  SECTION 
via  level  01  entries.  This  should  also  be  done 
for  1-0  CONTROL  statements. 

•  Avoid  literals  in  arithmetic  statements  using 
ADD,  SUBTRACT,  MULTIPLY,  and  DIVIDE. 

•  Use  data  names  rather  than  literals  in  loop 
controlled  PERFORMS. 


•  Parameterize  your  own  carriage  control  characters 
and  use  them  in  ADVATtfCING  clauses. 

•  Make  full  use  of  the  SPECIAL  NAMES  paragraph  to 
assign  mnemonic  names  to  hardware  devices  and 
switch  states. 

•  Recognize  the  FILE-CONTROL  paragraph  as  a 
parameterization  of  hardware  device  names. 

•  Quote  marks  are  often  non-compatible  -  check  for 
compiler  control  card  input  to  adjust  for  this. 

Apparently  missing  from  COBOL's  parameterization  capabilities 
are  provisions  for  OCCURS  phrases  (table  size)  and  PICTURE 
structure  (size,  scaling  and  precision).  These  items  require 
re-coding  for  each  change. 

2.1.6  Code  Restraints 

Every  COBOL  compiler  implementation  will  contain  individual 
author  and  machine  eccentricities.  It  is  very  important  that 
knowledge  of  these  idiosyncracies  is  not  used  to  produce 
unobvious  or  "trick"  results.  There  is  no  guarantee  that 
successive  compilers  will  exhibit  the  same  results  or  that  the 
"clever"  programmer  will  be  around  to  patch  things  up. 

In  addition,  unexperienced  programmers  may  not  be  aware  of  the 
existence  of  alternate  interpretations  and  mechanizations  which 
could  be  applied  to  their  coding.  For  these  reasons,  the  follow¬ 
ing  list  is  included.  It  is  a  brief  summary  of  techniques  which 
may  create  unpredictable  results  when  transferred. 

•  Implied  subjects  in  IF  statements,  though  usually 
acceptable,  may  cause  ambiguous  meaning  when  used 
with  NOT.  For  example: 

IF  X  NOT  LESS  THAN  6  OR  GREATER  THAN  9  GO  TO  PARI 
may  be  interpreted  as 

IF  X  NOT  (LESS  THAN  6  OR  GREATER  THAN  9) 
in  Burroughs  implementations,  or  as 
IF  X  (NOT  LESS  THAN  6)  OR  GREATER  THAN  9 
in  IBM  compilers. 
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•  Multiple  conditions  IF  IF  should  be  avoided. 

•  Do  not  assume  that  if  the  GIVING  phrase  is  omitted 
in  MULTIPLY  X  BY  Y  that  the  result  will  replace  Y. 

•  Use  ON  SIZE  ERROR  whenever  numeric  data  may  be 
close  to  0. 

•  Be  careful  about  utilizing  very  long  records  in 
I/O. 

•  READ  statements  executed  after  execution  of  an  "AT 
END"  clause  may  produce  bad  results. 

•  SYNCHRONIZE  clauses  are  hardware  dependent • regard¬ 
ing  the  format  o *  external  media  (tape)  containing 
items  of  this  type  and  the  generation  of  implicit 
FILLER  when  the  preceding  item  does  not  terminate 
on  a  word  boundary. 

•  No  implied  background  characters  should  be  assumed; 
un-ini tialized  areas  may  result  in  random  printer 
control  cnaracters  on  output. 

•  No  rules  are  given  to  control  the  way  in  which  arith¬ 
metic  is  done;  thus  the  compiler  may  perform  calcula¬ 
tions  in  binary,  BCD,  packed  demical,  etc.  Only  the 
result  is  required  to  be  in  the  proper  form.  This 
implies  the  following: 

.  Limit  arithmetic  operations  to  two  operands  when 
possible  to  avoid  intermediate  result  differences. 


Do  rounding  by  adding  5  X  10n  where  n  is  one 
greater  than  desired  accuracy. 

.  If  there  are  more  places  to  the  left  of  the 
assumed  decimal  point  than  in  the  data  item 
assigned  to  the  answer,  extra  digits  will  be 
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dropped  or  execution  may  stop.  Therefore,  use 
SIZE  ERROR  options  when  this  is  a  possibility. 

.  COMPUTATIONAL  and  COMPUTATIONAL- n  internal 
representations  vary  greatly.  For  example, 

Honey w® 11  COMP-1  is  binary  and  COMP  is  packed 
decimal  while  IBM  is  just  the  opposite.  The 
programmer  may  well  try  to  use  binary  items 
exclusively. 

•  Comparison  of  data  of  unequal  type  and  size  produces 
non-uniform  results. 

•  Do  not  MOVE  groups  to  elementary  elements  due  to  vary¬ 
ing  justification  and  size  problems. 

•  Do  not  MOVE  blanks  to  numeric  items  and  expect  0's. 

•  MOVE  ALL  to  a  field  containing  a  decimal  point  may  or 
may  not  terminate  the  MOVE  at  the  decimal  point. 

•  LABEL  processing  is  not  standard. 

•  Automatic  end  of  reel  and  end  of  file  processing  is 
done  in  many  ways;  take  care  in  these  situations  when 
transferring  programs. 

•  Do  not  assume  that  the  IF  name  GREATER  THAN  "Z"  state¬ 
ment  will  be  a  saf-  numeric  test  even  if  it  does  save 
time  and  core.  A  standard  COBOL  collating  sequence 
has  not  been  defined.  Hence  the  following  holds  true: 

Special  characters  <A-Z  <0-9  for  IBM,CDC, RCA,XDS 
whi  ie 

0-9  •'Special  <A-Z  for  GE  and  Honeywell. 

•  Differences  in  collating  sequence  produce  differences 
in  LGw-VALUE  and  HIGH-VALUE  computations. 

•  The  card  codes  for  +="'();  @  may  have 
differences  between  hardware  while  *  -  /  $  ,  .  are 
common. 

•  All  numeric  fields  used  in  computations  should  be 
defined  as  signed. 
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•  If  a  numeric  field  is  to  be  used  mathematically, 
define  it  as  COMPUTATIONAL. 

2.1.7  Policy 

When  some  reasonable  adherence  to  a  standard  is  enforced,  COBOL 
source  programs  can  be  coded  in  such  a  fashion  that  transferabil¬ 
ity  problems  between  various  machines  and  compiler  implementations 
are  minimal.  Much  of  this  power  is  due  to  the  inherent  separa¬ 
tion  of  DATA  and  PROCEDURE  coding  and  the  relative  word/byte 
size  independence  of  the  data  description.  Compiler  restrictions 
on  ENVIRONMENT  descriptions,  when  supplemented  by  programmer 
efforts,  also  contribute  to  the  recognition  and  isolation  of 
system  dependent  features. 

Frustratingly  often,  it  is  individual  compiler  interpretations 
and  extensions  and  not  the  hardware  that  introduces  idiosyncra- 
cies  which  interfere  with  smooth,  rapid  program  transfers. 
Operating  system  interfaces  (which  are  not  dealt  with  here)  also 
provide  conversion  difficulty  even  when  running  on  the  same 
hardware.  In  order  to  overcome  such  restraints,  a  small  loss  in 
execution  efficiency  must  be  accepted. 

In  general,  the  use  of  a  compiler's  extensions  will  result  in 
incompatibility  to  any  other  compiler.  Any  shorthand  or  non-use 
of  Standard  required  syntax  should  be  considered  an  extension 
and  avoided.  This  includes  abbreviations  such  as  PC  for  PICTURE 
and  implied  subjects  in  IF  statements.  In  addition,  special 
character  shorthands  such  as  >for  GREATER  THAN  should  not  be  used 
since  some  machines  don't  have  these  characters.  Similarly, 
even  though  a  number  of  compilers  accept  *  in  the  continuation 
column  as  a  NOTE,  many  do  not. 

Another  general  suggestion  is  to  always  use  at  least  one  alpha¬ 
betic  character  or  hyphen  between  the  first  and  last  characters 
of  a  name  (some  implementors  reject  all-numeric  procedure  names 
for  instance) . 


A  form  of  abbreviation  which  may  not  be  overlooked  is  the  COMPUTE 
verb.  Arithmetic  computations  can  be  done  with  less  space  and 
time  if  COMPUTE  is  used,  but  intermediate  result  handling 
(especially  truncation)  is  implemented  in  a  variety  of  ways^ 

Many  of  the  techniques  are  very  machine  dependent  and  final 
results  may  vary  from  machine  to  machine.  If  consistency  of 
results  is  important,  the  basic  ADD,  SUBTRACT,  MULTIPLY,  and 
DIVIDE  verbs  with  two  operands  should  be  utilized. 


In  one  of  the  previous  sections,  the  use  of  DISPLAY  characters 
for  final  output  (to  another  compiler/machine)  was  recommended 
since  this  form  of  data  representation  is  the  most  compatible. 
Unfortunately,  problems  do  exist  in  transferring  DISPLAY  gener¬ 
ated  tapes  between  some  machines  such  as  UNIVAC  and  IBM.  In 
these  situations  assembly  level  utilities  will  probably  be 
necessary.  If  possible,  the  use  of  data  records  which  are  a 
multiple  of  24  bits  (3  or  4  characters)  may  aid  in  this  conver¬ 
sion  process. 

Many  installations  concerned  with  transferability  problems  have 
adopted  additional  techniques  not  previously  mentioned.  In  some 
firms,  for  instance,  name  qualification  has  been  ruled  out  and 
"uniqueness"  is  considered  to  be  part  of  the  standard.  This 
helps  avoid  confusion  when  maintenance  must  be  performed  by 
someone  other  than  the  original  author. 

Another  approach  is  suggested  by  products  which  perform  pre¬ 
compilation  of  COBOL  programs  with  a  pre-defined  library  of 
standards  to  be  checked.  If  the  COBOL  program  in  question  vio¬ 
lates  any  of  the  rules  set  up  by  the  standards  group,  appropriate 
error  flags  and  severity  codes  are  issued.  Some  of  the  more 
popular  restrictions  include  separate  cards  for  paragraph  names, 
minimum  name  lengths,  ACCEPT  is  not  allowed,  qualification  is 
not  allowed,  REVERSED  is  illegal,  and  many  more. 

Fortunately,  listings  of  COBOL  source  statement;  provide  fairly 
good  documentation  and  ease  the  burden  often  experienced  in 
changes  or  additions  to  other  higher  level  languages  such  as 
FORTRAN.  This  facility  can  be  furthered  by  writing  COBOL  state¬ 
ments  such  that  phrases  common  to  most  compilers  are  separated 
from  those  that  must  be  varied  to  satisfy  individual  require¬ 
ments.  In  the  example: 

SELECT  file-name  ASSIGN  TO 

device-name 

only  the  card  with  the  device  name  would  require  change.  This 
technique,  though  seemingly  trivial,  can  do  alot  to  isolate  and 
identify  probable  changes  and  will  even  save  a  little  keypunch 
time. 

Some  other  commonly  used  ideas  to  increase  self  documentation 
and  facilitate  maintenance  of  COBOL  programs  are: 

•  Final  source  decks  should  be  carefully  sequenced  by 
at  least  an  increment  of  10  per  card. 


•  Do  not  qualify  fields.  It  is  better  to  say 
"MOVE  IN-PAYMENT  TO  OUT-PAYMENT" 

than  to  use 

"MOVE  PAYMENT  OF  IN- RECORD  TO  PAYMENT  OF  OUT-RECORD". 

•  Define  subscripts  in  a  descriptive  way.  For  example: 
TABLE-SUBSCRIPT  or  ARRAY-INDEX. 

•  Data  structures  should  be  incremented  in  a  fixed 
amount  larger  than  one  to  facilitate  change. 

01  FIRST-STEP 
05  SECOND-STEP 
10  NEXT-STEP 

•  Isolate  verbs  and  nouns  in  some  fixed  field  format  for 
ease  of  reading. 

ADD  DOLLARS  CENTS  GIVING  TOTAL 

MOVE  TOTAL  TO  OUT-T 

PERFORM  ROUTINE1 
WRITE  OUTPUT-BUF 

9  Notes  may  be  more  easily  recognized  when  set  off  by 
dashes . 

NOTE—— THIS  IS  IMPORTANT 

•  When  an  error  occurs,  print  all  pertinent  information 
and  branch  to  the  end  of  job  if  possible. 

•  Perform  a  paragraph  name  by  specifying  beginning 
and  ending  names.  For  example: 

PERFORM  PARAG1  THRU  PARAGI-EXIT 


PA  RAG  1 . 


PARAGI-EXIT. 

EXIT. 
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•  Use  indentation  whenever  applicable.  For  example: 

IF  TODAYS-DATE  IS  LESS  THAN  DEADLINE 
MOVE  DOLLARS  TO  PAYMENT 
GO  TO  NEXT- STEP 
MOVE  XSIZE  TO  TAX 

In  perspective,  it  is  reasonable  to  expect  many  additions  and 
improvements  to  be  made  to  Standard  COBOL.  It  may  also  be  ass¬ 
umed  that  some  companies  will  find  extensions  and  dialect  changes 
worth  the  additional  transferability  problems  they  create.  Every 
effort  must  be  made  to  insure  that  these  improvements  and  devia¬ 
tions  are  incorporated  in  an  orderly  fashion  and  thac  potential 
problems  are  identified,  documented  and  isolated  whenever  possi¬ 
ble.  This  requires  implementor  awareness  (IBM  currently  flags 
most  extensions  in  their  COBOL  manuals)  and  user  diligence. 
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2.2  FORTRAN  PROGRAMMING  FOR  TRANSFERABILITY 


2.2.1  Introduction 

In  November  of  1954,  International  Business  Machines  introduced 
the  "IBM  Mathematical  FORmula  TRANslation  System,  FORTRAN",  a 
language  designed  to  permit  users  a  facility  for  solving  complex 
mathematical  problems  on  a  computer  without  intimate  familiarity 
with  that  computer.  Today,  FORTRAN  has  achieved  world  wide  user 
acceptance  and  has  be.jn  implemented  on  nearly  every  major  compu¬ 
ter  .  Although  originally  intended  for  mathematical/engineering 
applications,  FORTRAN  is  now  used  for  a  variety  of  other  daca 
processing  activities. 

With  wide  user  acceptance,  however,  comes  a  multitude  of  exten¬ 
sions  of  what  is  considered  standard  FORTRAN.  This  prolifera¬ 
tion  of  dialects  has  hampered  FORTRAN'S  universal  transferability. 
Since  FORTRAN  IV  is  the  most  widely  used  version  and  a  standard 
has  been  developed  for  it,  all  further  references  will  be  to 
FORTRAN  IV. 

In  the  following  sections,  information  will  be  presented  on 
dialect  differences  and  their  impact  on  transferability,  unique 
system  environment  attributes  such  as  character  sets,  machine 
dependent  practices  to  avoid,  program  organization  to  maximize 
transferability,  parameterization  possibilities,  compiler  imple¬ 
mentation  technique  variations  and  the  ensuing  code  restraints, 
anc  finally,  examples  of  alternatives  to  our  suggestions  and 
justification  of  the  warning?  given. 

2.2.1  Dialects 

Unfortunately,  almost  as  many  dialects  of  FORTRAN  IV  exist  as  do 
machines/systems  on  which  the  language  has  been  implemented,  if 
not  more  (witness  IBM  360  levels  F,  G,  H) .  Some  versions  contain 
simple  logical  extensions  of  the  basic  computational  capabilities 
such  as  mixed  mode  arithmetic  involved  expressions  for  sub¬ 
scripts,  or  conditional  looping.  Other  implementations  involve 
system  environment  extensions  such  as  di  ik- oriented  I/O  instruc¬ 
tions  (FIND,  DEFINE  FILE).  For  obvious  purposes  then,  we  will 
reference  ail  discussion  of  extensions,  mutations  and  their 
relative  costs  to  transferability  to  the  ANST-X3 . 9-1966  Standard 
FORTRAN.  Although  this  document  seems  to  represent  the  majority 
opinion  of  what  constitutes  standard  FOLTRAN,  it  should  be  noted 
that  the  ANSI  version  is  j.n  itself  an  extension  of  early  FORTRAN 
IV  dialects. 


The  ramifications  of  using  extended  or  "non-standard"  diale«.  \s 
can  be  numerous  and  far  reaching.  Consider,  for  c  cample,  a 
company  which  purchases  a  computer  and  associated  software 
including  a  large  FORTRAN  system.  After  a  few  years  of  full 
utilization  of  their  "improved"  FORTRAN,  it  becomes  desireable 
to  switch  to  a  new  system  with  more  speed,  additional  storage, 
better  peripherals,  etc.  Upon  consideration  of  several  alterna¬ 
tives,  it  is  decided  that  System  Z  (a  different  manufacturer)  .  t 
by  far  the  superior  product  and  that  a  changeover  should  be 
initiated  immediately.  In  choosing  the  new  computer,  it  may  at 
first  seem  that  additional  costs  will  be  incurred  only  for  mi cor 
job  control  interfaces  and  the  new  hardware.  It  is  soon  dis¬ 
covered,  however,  that  the  new  FORTRAN  does  not  support  the  same 
deviations  and  extensions  as  the  current  system  and  that  re-pro¬ 
gramming  costs  will  be  a  significant  percentage  of  t.  i  original 
development  outlay.  The  obvious  result  is  that  many  have  become 
"locked-in"  to  a  particular  manufacturer.  In  this  case  :i  would 
have  been  wise  to  avoid  extensive  use  of  non-standard  features, 
or  at  least  to  have  recognized  and  isolated  exceptions. 

To  fully  document  all  deviations  ever  conceived  or  realizec  seems 
an  ambitious  task.  For  this  reason,  it  was  decided  to  illustrate 
the  most  common  dialect  differences  by  reviewing  several  popular 
implementations.  Specifically,  IBM  7094,  OS  360,  CDC  6600,  XDS 
Sigma  5/7,  and  Burroughs  B5500  computer  systems  were  investigat¬ 
ed.  The  tables  that  follow  include  examples  of  notable  exceptions 
to  the  standard  and  estimates  of  their  cost  impact  on  transfer- 
ability  as  well  as  the  expected  increased  effort  necessary  to 
avoid  their  use.  These  symbols  used  to  represent  the  relative 
import  of  each  attribute  are  defined  in  the  introduction  to 
Section  2. 
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STANDARD  DIALECT  DEVIATIONS  CHART 
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2.2.3  System  Environment 

It  is  difficult  to  control  or  predict  the  machines/systems  on 
which  a  program  may  someday  be  compiled.  There  are,  however, 
several  actions  that  can  be  taken  to  avoid  system  environment 
impact  on  transferability.  An  awareness  of  the  many  items  which 
are  likely  to  be  unique  in  a  given  environment  can  be  of  great 
importance  in  planning  programs  to  minimize  and  isolate  system 
dependencies.  The  following  two  lists  show  attributes  to  con¬ 
sider  in  system  changes  and  practices  to  avoid  m  general. 

Unique  Attributes  to  Consider 

1.  Word  size  and  precision. 

2.  Character  size  and  the  effect  on.  core  space  and 
character  oriented  coding.  Example: 


DATA  MX/6HCHARAC , 6HTER - /  versus 

DATA  MX/4HCHAR, 4HACTE , 4HR - / 

Logical  unit  assignments. 

Peripherals  available  (number  and  kind) . 

BCD,  EBCDIC  card  code  differences. 

Time  controls. 

Block  and  segment  command  words  affixed  to  binary 
tape  records. 

Maximum  and  minimum  record  size  constraints. 

Printer  and  typewriter  line  size  and  character 
sets . 

Incremental  compiler  restrictions  (order  of 
statements) . 

Internal  representation  (hex,  octal,  binary). 

Core  size. 
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Practices  tc  Avoid 


1.  Multiple  file  I/O.  (OS  360,  not  available  on 
other  machines.) 

2.  Special  disc  or  drum  oriented  instructions. 

3.  Literal  unit  assignments. 

4.  Special  system  routines  such  as  sense  switch 
options . 

5.  Typewriter  I/O. 


6.  Use  of  hex  and  octal  literals  (internal 
representations) . 

7.  Special  characters  (other  than  A-Z,  0-9,  +  , 
*,  /,  (,),  ,,  $  and,  ANSI  standards). 

8.  Format  controlled  records  of  wSre  than  120 

characters.  . 


9.  Assembly  language  interfaces. 

10.  STOP  and  PAUSE  (differing  system  response). 

11.  Assuming  pre-ini  t.i  alized  memory. 

12.  .✓Character  tests  with  machine  dependent  coding 

(input  the  character  set) . 

13.  Excessive  use  of  labelled  COMMON  (insufficient 
blank  COMMON  may  result  in  the  inability  to  load 
in  OS  360  due  to  loader  sharing  of  that  space) . 

14.  Word,  byte,  character,  or  sign  implementation 
dependent  coding. 

2.2.4  Modularity 

The  ability  to  divide  machine/system  dependent  and  independent 
attributes  into  separate  entities  via  sub-programs  greatly  en¬ 
hances  the  transferability  of  programs.  Furthermore,  the 
ability  to  compile  these  entiti  .s  individually  aids  in  the 
speedy  checkout  of  transferred  modules.  FORTRAN  is  exceptional 
in  the  ease  to  which  it  facilitates  modularity.  The  FORTRAN 
programmer  may  write  his  program  as  a  collection  of  small 
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routines,  compile  and  test  them  individually,  and  put  them 
together  in  a  building  block  fashion  into  large  ass  .nblages  with¬ 
out  recompilation.  Only  subroutines  that  are  modified  or 
corrected  ever  need  be  recompiled.  In  this  way,  machine  depen¬ 
dent  code  may  be  economically  isolated  into  separate  modules. 

Assuming  that  the  isolation  of  system  dependencies  is  feasible, 
the  dependent  segment  should  be  i eparated  into  relatively  homo¬ 
genous  sub-segments.  This  is  necessary  because  some  aspects 
will  not  be  as  dependent  as  others  (formatted  versus  unformatted 
input/output,  for  example) . 

Similarly,  it  may  not  be  possible  to  completely  purge  an  inde¬ 
pendent  section  of  transfer  problems.  Thorough  checks  should 
be  made  for  obscure  problems  connected  with  machine  characteris¬ 
tics  such  as  precision  and  round-off.  Parameterization  may  be 
of  help  in  this  area. 

Programs  written  in  FORTRAN  usually  contain  the  following 
grouping: 


Dependent 

Special  input/output 
Error  checking  and  recovery 
Operating  system  interface 
Character  set 
Data  masks 


Independent 

Program  logic 
Calculations  (except 
for  precision) 

Data  movement 


a  typical  program  can  be 


With  this  functional  grouping  in  mind 
designed  (divided)  into  the  following  modules. 


•  Main  control  (independent) 

.  Calls  computational  routines 
.  Calls  dependent  routines 
.  Calls  main  control  loop 
,  Calls  independent  exit  routine 
.  Capable  of  compilation  on  very  basic  system 

•  Dependent  initialization 

.  Sense  lights,  overflow  indicators,  etc. 

.  Character  set  (read  in) 

.  Format  statements  (read  in) 

.  Parameters  (word  size,  character  size,  etc.) 
.  Calls  ERROR  routine 
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•  Main  control  loop  (independent) 

.  Calls  independent  initialization 
.  Defines  blank  COMMON 

.  System  independent  tests  and  calculations  to 
drive  the  job 
Calls  input  routines 
.  Calls  ERROR  routine 
.  Calls  output  routines 
.  Loop  control 
.  Calls  general  program 
.  Returns  to  main  control 

•  Operating  system  interface  (dependent) 

.  Mechanism  to  exit  system  and  dump 
.  ERROR  routine 

.  Unformatted  I/O  routine  (entered  via  computed  GOTO) 

•  Independent  initialization 

.  Usual  program  initialization  process 
.  Calls  to  operating  system  interface 

•  ERROR  routine  (dependent) 

.  Handles  sense  lights,  overflow  check,  etc 
.  Handle  recoverable  errors  (parity,  end  files,  etc.) 
.  Calls  dump  routines 

•  Formatted  input/output  'independent) 

.  All  formatted  input/output 
.  Controlled  by  computed  GOTO 

•  General  program  (independent) 

.  All  calculations,  data  handling  and  program  logic 
not  present  in  separate  modules. 

Calls  dependent  routines 

2.2.5  Parameteri zation 

Specification  of  machine/system  dependent  aspects  by  way  of 
coded  or  card  input  parameters  would  indeed  aid  program  trans¬ 
ferability.  Unfortunately,  many  of  the  features  such  as  word 
size,  byte  size,  core  size,  record  length  and  type,  are 
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deeply  imbedded  in  individual  compiler  designs  or  have  simply 
been  overlooked.  For  instance,  the  number  of  characters  per 
word  is  inherent  in  hollerith  definitions  such  as  DATA/X/6HABC 
DEF/.  Similarly,  there  is  no  easy  way  to  reduce  the  dimensions 
of  arrays  in  COMMON.  Of  course,  it  has  always  been  good  pro¬ 
gramming  technique  to  parameterize  such  things  as  DO  loop  indi¬ 
ces  or  logical  unit  assignments,  but  much  more  is  needed  in  this 
area.  Although  there  have  been  a  few  contributions  such  as 
variable  dimensions  in  subroutines,  transferability  of  applica¬ 
tion  programs  must  be  taken  more  into  account  in  future  FORTRAN 
compiler  implementations  and  revisions  of  the  Standard. 

2.2.6  Code  Restraints 

Many  commonly  utilized  techniques  or  "tricks"  in  FORTRAN  programs 
are  sever ly  detrimental  to  program  portability  because  of  mach¬ 
ine/implementation  differences  inherent  to  individual  compilers. 
The  following  list  is  a  sample  taken  from  knowledgeable  users 
of  such  tricks. 

Coding  Techniques  With 
Unpredictable  Variations 

1.  Testing  for  0.  Example:  IF(X.EQ.O.O)  GO  TO  10 

2.  One  terminal  statement  for  a  nested  DO  loop  exit, 

3.  Termination  of  a  DO  with  a  complex  statement  such 
as  an  IF. 

4.  Literal  strings  of  excessive  length  (>255  characters). 

5.  Altering  a  DO  parameter  within  the  loop. 

6.  Ambiguous  statements  such  as 

N=N+FUNC (N) *N  where  FUNC  (N)  alteis  N. 

7.  Double  exponentiation:  A**B**C. 

8.  Assumption  that  some  finite  value  will  be  su  ti- 
tuted  for  a  division  by  0. 

9.  Recursive  subroutines. 

10.  Variable  length  argument  strings  in  subroutine 
CALLS . 


81 


11.  Scattered  specification  statements. 

12.  Shifting  by  multiplication. 

13.  Using  large  numbers  as  DO  indices.  Example: 

DO  10  1=1,  N  where  N  =  217 

14.  Assuming  a  loop  is  always  executed  once.  Example: 

DO  10  1=4, N  where  N  =  3 

15.  Transferring  into  a  DO  r>'ge. 

16.  Assuming  the  value  of  an  index  outside  a  DO  loop. 

17.  Returning  from  a  subprogram  via  an  assigned  GO  TO. 

18.  Assuming  an  incorrect  computed  GO  TO  variable  will 
result  in  a  default  condition  such  as  "falling  through". 

2.2.7  Policy 

Regardless  of  individual  arguments  against  the  Standard  FORTRAN, 
it  seems  that  only  strict  adherence  to  this  definition  will 
minimize  transferability  problems.  Although  intended  for  con¬ 
venience  and  versatility,  extensions  of  the  Standard  base  will 
eventually  lead  to  severe  restriction  and  user  dependence  on 
particular  suppliers'  products.  In  addition,  programmers  work¬ 
ing  in  an  environment  which  allows  broad  variations  of  FORTRAN 
will  experience  re-adjustment  difficulties  when  attempting  to 
code  on  other  systems;  hence,  programmer  transferability  cost 
is  also  a  factor. 

If  an  organization  is  committed  to  non-standard  dialects,  every 
effort  should  be  made  to  utilize  the  Standard  recommendations  as 
a  documentation  guideline.  All  deviations  should  be  listed 
along  with  estimates  of  their  diversity  and  importance  to  the 
individual  program  (see  Section  1.4). 

If  possible,  compilers  th.it  are  non-standard  should  include 
diagnostics  pointing  out  these  extensions/modifications  as 
potential  problems.  An  example  of  this  approach  is  the  WATFOR 
FORTRAN  compiler  developed  by  the  Univeisity  of  Waterloo.  WAT¬ 
FOR  ..lags  its  own  extensions  and  also  attempts  to  point  out 
(via  diagnostics)  system  dependent  code  such  as  uninitialized 
variables . 
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Many  general  policies  which  will  aid  in  program  design  are 
summarized  in  the  following  list. 


General  Guidelines 

1.  Avoid  usage  of  extensions  to  the  Standard 
whenever  possible. 

2.  Document  extensively  all  dialect  variations  and 
machine/system  dependent  code,  functions,  general 
design,  etc. 

3.  Modularize  programs  into  machine/system  dependent 
and  independent  sections. 

4.  Avoid  assembly  language  code  interfaces. 

5.  Do  not  use  programming  tricks  dependent  on  machine 
idiosyncracies . 

6.  Design  magnetic  tape  outputs  for  general  compati¬ 
bility.  Avoid  complicated  blocking  or  binary  (non- 
formatted)  final  outputs. 

7 .  Lay  out  blank  COMMON  in  one  central  routine  and 
treat  variables  there  as  if  they  were  global. 

This  avoid  duplication  and  is  a  form  of  documentation. 

8.  Always  initialize  memory  even  if  your  present  system 
does  it  for  you. 

9.  Always  assume  the  character  set  is  variable.  Do 

not  make  programs  dependent  on  the  internal  character 
representation  of  a  particular  machine. 

10.  Avoid  operator  inter-action  (typewriter  I/O). 

11.  Plan  to  end  up  with  a  test  package  which  can  be 
used  in  future  transfers. 

12.  Estimate  the  range  of  data  values  and  document  same. 
The  precision  of  integer  and  floating  arithmetic  is 
machine  and  software  dependent.  If  future  systems 
have  fewer  bits  assigned  to  the  characteristic  in 
floating  point  representations,  for  example,  the 
current  data  may  generate  over/underflows  (which 
may  go  undetected) . 


After  the  program  is  complete  and  a  system  change  occurs,  tne 
following  checklist  may  help  detect  potential  problems. 

Checklist  for  Transferring  a  Program 
From  One  Machine  to  Another 

1.  Does  FORTRAN  exist  on  the  new  machine/system? 

2.  Is  the  new  machine's  core  size  adequate? 

3.  Are  all  intrinsics  available? 

4.  Are  all  library  routines  available? 

5.  Is  the  10RTRAN  standard? 

6.  Are  word,  ar.d  byte  size  the  same? 

7.  Is  the  precision  adequate? 

8.  Is  internal  representation  the  same?  (Octal,  hex, 
binary,  etc.) 

9.  Is  the  character  set  the  same?  Must  card  decks  be 
converted? 

10.  Are  necessary  peripheral  devices  available  and 
adequate? 

11.  Does  operating  system  interface  necessitate  changes 
in  the  code?  (i.e.  are  the  systems  CALLs  the  same?) 

12.  Can  assembly  language  routines  be  re-written  easily? 

13.  Can  the  machine  characteristics  be  defined  in  an 
initializing  subroutine? 

14.  How  will  machine  speed  affect  the  programs?  Must 
some  be  re-written  for  more  efficiency? 

15.  Are  all  necessary  FORTRAN  statements  available? 

16.  Does  the  machine/system  depondence/independence 
modularity  still  hold? 

17.  What  about  data?  Can  some  be  used  without  reformatting 
Do  tapes  have  to  be  converted? 


18.  Will  possible  record  size  changes  cause  any  storage 
problems? 

19.  Can  rapid  change  and  checkout  be  made?  If  not, 
why  not? 

20.  Recompile  independent  modules  first.  Any  errors 
which  are  encountered  may  signify  some  basic  problems. 

Many  of  the  suggestions  made  in  previous  sections  involve  trade¬ 
offs  wich  perhaps  should  be  individual  management  decisions. 

In  modularity,  for  example,  design  of  relatively  independent 
subprograms  greatly  enhances  transferability,  but  it  also  will 
increase  execution  time  in  most  cases.  If  the  project  leader 
feels  that  modularization  will  severely  hamper  the  development/ 
efficiency  of  the  program  and  also  that  the  application  is  short 
term  and  will  surely  not  .-^ed  to  be  transferred,  then  obviously 
the  suggestions  made  in  2.2.4  should  be  discarded. 

With  regard  to  extensions  of  the  Standard,  a  general  policy  of 
avoidance  is  a  good  one.  However,  the  programming  manager  may 
feel  that  the  use  of  particular  additional  capabilities  present 
in  his  dialect  is  of  such  importance  that  it  outweighs  the 
obvious  transfer  problems  it  will  create.  Again,  as  suggested 
in  1.4,  at  least  document  and  attempt  to  isolate  these  exten¬ 
sions  . 

Also,  it  is  apparent  that  some  programs  simply  cannot  be  trans¬ 
ferred.  An  in-core  sort  based  on  at  least  128K  bytes  of  storage 
for  tables  may  be  impractical  on  a  machine  with  only  32K  bytes. 
Similarly,  if  a  scientific  analysis  program  currently  takes  one 
hour  to  run  and  a  transfer  is  proposed  to  a  machine  with  1/10 
the  speed,  it  may  no  longer  be  economically  feasible  to  utilize 
this  routine.  This  brings  out  another  basic  policy  considera¬ 
tion  in  program  design.  The  manager  should  influence  design 
decisions  based  on  speed,  accuracy  and  core  space  keeping  in 
mind  how  the  particular  computer  now  being  utilized  relates  to 
other  possible  future  machines.  For  instance,  if  the  current 
application  computer  has  36  bits  and  at  least  34  bits  are  re¬ 
quired  for  accuracy  of  computations,  perhaps  double  precision 
should  be  used  anyway  since  a  transfer  to  a  computer  with  32 
bits  may  involve  extensive  reprogramming.  Again,  this  may  be 
a  management  trade-off  (speed  versus  reprogramming)  decision. 

The  same  reasoning  applies  to  speed  versus  table  size  considera¬ 
tions* 


So  that  there  is  no  misunderstanding  about  code  restraint 
implications  listed  previously,  the  following  justifications 
are  included: 


1.  Due  to  inherent  inaccuracies  of  floating  point 
representations,  it  may  happen  that  a  test  for  a 
specific  number  will  fail  when  actually  it  should 
pass.  For  example: 

A  =  1.  -  2. 0/2.0  may  come  out  to  be  .0000001 

and  a  subsequent  test  for  (A.EQ.0.)  would  fail. 

2.  Some  compilers  put  special  restrictions  on  nested  DO 
loops  that  terminate  on  one  statement.  XDS  Sigma 
5/7,  for  instance,  only  allows  the  inner  most  DO  to 
transfer  directly  to  its  termination  point. 

3.  Compilers  which  allow  termination  of  DO  loops  on 
IF  statements  disclaim  the  predictability  of 
results  (XDS  Sigma) . 

4.  Compilers  may  have  inherent  table  size  restrictions 
on  character  string  length  (CDC). 

5.  Altering  a  DO  parameter  within  a  loop  may  produce 
varying  results  depending  on  the  mechanization  of 
the  DO  (pre  test,  post  test,  index  in  core,  index 
in  register,  etc.) 

6.  Ambiguous  statements  such  as 

N=N+FUNC (N) *N 

depend  on  the  mechanization  of  the  scanning  a.1  ,orithm 
If  the  original  value  of  N  is  not  stored  in  another 
temporary  location  FUNC(N)  may  destroy  it. 

7.  Double  exponentiation  A**B**C  is  also  not  defined 
in  the  Standard  and  is  dependent  on  the  mechanized 
algorithm 

(AB)C  or  (A)bC 

.  *>Q 

8.  Division  by  0  may  result  in  values  0,  10  ,  etc. 

depending  on  the  system. 


9.  Most  compilers  do  not  allow  recursive  subroutines. 


10. 


Some  compilers  will  not  deal  successfully  with 
missing  arguments  (variable  length)  in  a  sub¬ 
routine  CALL  (mechanized  at  the  RETURN  and  assumes 
the  number  of  arguments  is  fixed. 

11.  Incremental  compilers  cannot  handle  scattered  type, 
dimension,  and  DATA  statements.  Yet,  this  form  of 
compiler  is  desirable  for  a  speed/user  interface 
stand-point. 

12.  Shifting  algorithms  are  word-size  and  hardware 
(multiplication,  sign  representation)  dependent. 

13.  Compilers  may  implement  DO  loops  in  index  registers 
(IBM  7090)  and  hence  set  an  upper  limit  on  index 
values . 

14.  Loops  of  the  form  DO  10  I=K,  J  where  J<K  may  or  may 
not  be  executed  once  depending  on  where  the  test  for 
completion  is  made. 

15.  Most  compilers  do  not  guarantee  the  results  of 
transfers  into  a  DO  loop. 

16.  The  addressing  scheme  of  some  machines/compilers 
allows  for  passing  of  statement  label  addresses  for  an 
assigned  GO  TO  to  subroutines. 

17.  Some  compilers  generate  code  for  testing  the  computed 
GO  TO  arguments.  The  last  statement  label  or  next 
statement  becomes  the  error  condition  default. 

In  summary,  the  use  of  FORTRAN  can  unquestionably  aid  in  program 
mobility  especially  when  applications  are  modularized  into  mach¬ 
ine/system  dependent  and  independent  sections.  Dialect  varia¬ 
tions  should  be  avoided.  Although  most  compilers  contain 
diagnostics  which  will  flag  illegal  code,  serious  design  prob¬ 
lems  may  result  when  machine/system  transfer  is  attempted. 
Undetected  errors  will  often  occur  when  special  tricks  or  mach¬ 
ine  dependent  algorithms  are  used.  Parameterization  of  crucial 
restraints  such  as  core  size,  and  word  length  are  needed  though 
FORTRAN  is  somewhat  deficient  in  this  area.  It  is  the  respon¬ 
sibility  of  the  programmer  to  follow  recommended  guidelines  and 
carefully  document  exceptions. 


2.3  JOVIAL  PROGRAMMING  FOR  TRANSFERABILITY 

2.3.1  Introduction 

Although  JOVIAL  has  been  developed  primarily  by  System  Develop¬ 
ment  Corporation  (SDC) ,  its  history  of  modifications  and  varying 
implementations  has  been  as  complex  as  FORTRAN'S.  The  basic 
objective  of  "Jule's  Own  Version  of  the  Internacional  Algebraic 
Language"  was  to  create  a  language  for  use  by  professional  pro¬ 
grammers  in  solving  large  complex  information  processing  problems. 
In  route  to  the  fairly  successful  fulfillment  of  this  objective, 
JOVIAL  has  been  involved  with  all  the  problems  associated  with 
efforts  to  avoid  dialects,  control  extensions  and  subsets,  main¬ 
tain  compiler  independence  and  attain  wide  usage. 

Originally  used  by  SDC  for  Air  Force  projects,  it  has  also  been 
adopted  by  the  Navy  and  Army  in  many  of  their  programming 
efforts  and  has  enjoyed  wide  acceptance  within  SDC.  In  June 
1967,  after  several  "official"  JOVIAL  specifications  had  been 
established  by  SDC,  the  Air  Force  issued  its  own  specifications 
of  JOVIAL  ( J3 )  as  the  standard  programming  language  for  Air 
Force  command  and  control  applications.  This  document,  Air 
Force  Manual  100-24,  is  considered  "the  standard"  in  the  prepara¬ 
tion  of  the  following  material. 

2.3.2  Dialects 

Standardization  of  languages  has  been  said  to  be  important  for 
two  reasons:  It  allows  the  transfer  of  programs  from  one  com¬ 
puter  system  to  another.  It  allows  the  transfer  of  programmers 
from  one  application  to  the  other.  The  consensus  of  opinion  on 
JOVIAL  is  that  the  first  reason,  program  transfer,  is  possibly 
less  important  than  the  second,  mair taining  a  staff  of  mobile 
programmers.  The  assumption  is  that  JOVIAL  applications,  large¬ 
ly  in  support  of  command  and  control  systems,  tend  to  be  much 
more  application  specif xc  than  routines  written  in  other  higher 
level  languages  such  as  FORTRA  .  Hence  transfer  may  be  imprac¬ 
tical  or  meaningless  in  many  instances.  Transferring  programmers 
between  applications,  on  the  other  hand,  is  aeemed  extremely 
important  with  great  emphasis  having  been  placed  on  programmer 
convenience  and  usability.  This  concept  seems  largely  respon¬ 
sible  for  the  adoption  of  a  standard  JOVIAL  (J3)  by  the  Air 
Force. 

From  a  transferability  standpoint,  we  must  assume  that  the  Air 
Force  standard  is  generally  acceptable  and  that  it  will  form 
the  basis  for  subsequent  recommence  .ions  that  may  be  made.  With 


88 


this  in  mind,  it  is  the  purpose  of  the  following  tables,  com¬ 
piled  from  descriptions  of  widely  used  J3  dialects,  to  point 
out  common  extensions  and  subsets  of  the  Air  Force  standard. 
Furthermore,  an  attempt  is  made  to  assign  relative  cost  factors 
to  these  extensions  in  terms  of  programmer  convenience  of 
initial  coding  and  transfer  re-work  (see  tables  at  the  beginning 
of  Section  2) .  The  compiler  implementations  used  for  this  study 
were:  Burroughs  D-825,  Hughes  3118M,  UNIVAC  1108,  Control  Data 
6000,  IBM  AN/FSQ-7. 
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It  was  almost  always  the  case  in  FORTRAN  that  a  particular  imple¬ 
mentation  had  numerous  extensions  but  virtually  no  deletions 
from  the  standard.  JOVIAL  compilers,  on  the  other  hand,  seem 
to  divide  changes  equally  between  additions  and  subsets. 

Extensions  may  be  dealt  with  in  advance  of  system  transfers  by 
simply  avoiding  them.  Trying  to  "guess"  what  will  be  left  out 
or  changed  in  the  next  system,  however,  is  no  easy  task.  In¬ 
deed,  in  the  event  that  current  JOVIAL  programs  are  to  be  trans¬ 
ferred  to  "smaller"  systems,  it  appears  that  recoding  cannot  be 
avoided.  Actually,  no  meaningful  or  predictable  common  subset 
seems  to  exist  among  popular  implementations.  Rather,  each 
compiler  tends  to  drop  or  alter  different  features.  The  follow¬ 
ing  list  of  unavailable  or  changed  aspects  of  JOVIAL  was  pro¬ 
duced  from  the  small  but  highly  utilized  computers  IBM  Q7, 
Burroughs  D-825  and  Hughes  H3118. 

J.t  is  not  intended  to  suggest  that  these  features  be  avoided 
since  they  are  only  a  representative  sampling.  Avoidance  of 
all  facets  of  JOVIAL  which  may  not  be  present  in  "some"  compiler 
implementation  may  very  well  result  in  a  null  capability.  It 
is  hoped,  however,  that  this  list  may  at  least  indicate  differ¬ 
ences  to  look  for  in  the  event  of  a  pending  system  change. 

Subsets  of  the  Air  Force  Standard 
and  Miscellaneous  Differences 

Attribute  System 

1.  No  variable  (ITEM)  range  specification.  Q7 

2.  Floating  point  not  available.  Q7 

3.  Transfer  around  CLOSE  declarations  must  be  pro-  Q7 
vided  by  the  programmer. 

4.  Storage  of  arrays  by  rows  rather  than  by  columns.  D-825 

5.  Absolute  addresses  not  permitted.  D-825 

6.  The  (*  *)  form  on  exponentiation  is  not  allowed.  Q7 

7.  Functions  CHAR, MANT, STRING, ’LOC  are  not  present.  Q7 

8.  Exponentiation  takes  precedence  over  negation:  D-825 

-3**2=-B2. 
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9.  Variables  assigned  to  items  with  fewer  bits  D-825 

are  truncated  from  the  right. 

10.  Variables  assigned  to  items  •  ith  more  bits  are  D-825 

left- justified  with  t.r;  iling  l  bits. 

11.  The  default  mode  Is  A  _'  S.  Q 7 

12.  CLOSE  names  are  not  allowed  as  inputs  to  a  Q7 

PROCEDURE. 

13.  DUAL  variables,  are  not  permitted.  D-825 

14.  Roundir  -'  (R)  :s  not  avaiiable.  D-825 

15.  Litera%  :  ems  must  be  less  then  5  or  a  multiple  H3118 

of  3  ch<?-  teis. 

16.  Medium  p..,king  (M ?  not  available.  H3118 

17.  Tables  and  arrays  may  not  be  the  output  para-  H3113 

meters  of  a  PROCEDURE. 


2.3.3  System  Environment 


Many  of  the  factors  which  were  recognized  as  system  environment 
sensitive  in  Section  2.2.3  (FORTRAN)  apply  to  JOVIAL  programs 
as  well.  The  impact  of  different  word  and  byte  sizes,  charac¬ 
ter  representations,  peripheral  devices  and  other  attributes 
unique  to  each  system  is  universal. 


Actually,  JOVIAL  programs  are  generally  more  dependent  on  the 
current  operating  environment  than  are  programs  coded  in  many 
other  higher  level  languages  such  as  FORTRAN.  This  is  not  to 
say  that  careful  choice  of  che  JOVIAL  capabilities  utilized  and 
generous  parameterization  will  not  be  effective  in  maximizing 
transferability.  Rather,  it  must  be  emphasized  that  failure  to 
recognize  potential  system  depende  t  situations  can  seriously 
complicate  subsequent  machine  transfers.  The  range  of  possible 
outcomes  is  due  in  large  to  the  number  of  environment  sensitive 
specifications  which  are  left  to  the  JOVIAL  programmer.  Some  of 
these  include: 


•  the  number  of  bits  per  variable  (ITEM) 


•  the  number  of  words  per  table  entry 
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•  literals  of  "unlimited"  length  packed  in  tables 

•  fixed  point  precision  -  the  number  of  bits  in 
the  fraction 

•  roundi c  v  or  truncation 

•  programmer  packed  tables 

•  formatting  of  I/O 

•  device  oriented  I/O 

Many  of  these  features  can  be  specified  parametrically.  When 
no  convenient  method  of  parameterization  exists,  however,  isola¬ 
tion  of  necessary  machine  dependent  functions  into  easily  recog¬ 
nizable  and  hopefully  changeable  modules  is  recommended. 

Perhaps  the  most  likely  candidate  for  isolation  in  JOVIAL  pro¬ 
grams  is  input/output.  One  of  the  reasons  for  the  system 
dependence  of  JOVIAL  I/O  commands  is  that  file  manipulation  is 
at  the  device  (rather  than  logical)  level.  Only  physical  rec¬ 
ords  in  the  file  are  addressed  and  after  initialization,  no 
JOVIAL  monitoring  takes  place.  Hence,  error  checking  by  means 
of  status  items  tests  (which  vary  from  system  to  system)  and 
even  data  conversions  (such  as  formatted  I/O  in  FORTRAN)  are 
left  entirely  to  the  programmer.  Needless  to  say,  a  great  deal 
of  machine  dependent  coding  and  duplicated  effort  is  generated 
in  this  process. 

A  possible  approach  to  minimizing  this  problem  is  the  creation 
of  a  system  library.  A  standard  set  of  routines  could  be  made 
up  from  an  outline  of  the  various  types  of  input/output  gener¬ 
ally  performed  and  included  with  each  application.  These 
PROCEDURES  would  include  FILE, OPEN, SHUT, INPUT, OUTPUT  declara¬ 
tions  and  status  constant  tests  for  end  of  file,  parity  errors, 
etc.  The  programmer  would  then  call  the  appropriate  routine 
and  pass  information  on  status  (in  terms  of  program  defined 
constants),  number  of  words,  array  addresses,  etc.  This 
approach  would  most  likely  foil ov;  the  lines  of  inherent  I/O 
used  by  FORTRAN  with  intermediate  buffering,  fixed  record 
lengths  and  similar  standardizations.  By  giving  up  some  free¬ 
dom,  the  programmer  would  produce  routines  which  could  be  trans¬ 
ferred  to  other  machines  by  re-writing  of  I/O  procedures  rather 
than  extensive  re-coding  of  every  application. 

Some  of  the  more  subtle  forms  of  system  environment  effect  on 
transferability  involve  the  basic  JOVIAL  commands  and  functions. 
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The  following  list  is  a  sample  taken  from  the  Air  Force  Standard. 
It  is  not  intended  to  be  an  exhaustive  accumulation  of  do's  and 
don't's,  but  is  intended  to  point  out  the  types  of  statements 
in  JOVIAL  which  should  be  used  with  caution  to  insure  a  minimum 
of  sy~*em  dependence. 


Machine  (Environment)  Dependent 


Aspects  of  the  JOVIAL  Language 


1.  The  use  of  the  BYTE  modifier  in  conjunction  with  non¬ 
literal  items  assumes  the  character  size  and  the  number 
of  characters  per  word. 


2.  The  BIT  modifier  assumes  word  size. 


3.  The  '  LOC  modifier  in  many  cases  assumes  fixed  addresses 
tor  variables. 


4.  CHAR  and  MANT  results  depend  directly  on  machine 
characteristics  and  floating  point  implementations. 

5.  When  STOP  is  used,  the  computer  may  take  alternate  action 
(including  bombing  out)  depending  on  the  computer  system. 

6.  Literals  exceeding  the  host  computer  word  size  or  packed 
partially  in  multiple  core  locations  will  encounter  mach¬ 
ine  dependent  restrictions  such  as  byte  boundary  alignment 
and  compiler  restrictions  such  as  starting  byte  (in  the 
word)  specification.  Thus,  literal  packing  by  the  pro¬ 
grammer  should  be  avoided,  and  code  referencing  such  items 
should  avoid  word  length  dependence . 


7.  Octal  constants  modifying  or  setting  literals  such  as 
BLANKS  =  0(6060)  are  word  size  and  character  set 
dependent. 


8.  The  ODD  function  may  produce  varying  results  with  regard 
to  the  negative  number  representation  of  the  machine. 

AFM  100-24  specifies  "ODD  designates  the  value  true  when 
the  least  significant  bit  is  one  and  false  when  it  is 
zero.  ODD  is  true,  therefore,  when  the  modified  variable, 
considered  an  integer,  is  odd."  Note  what  happens  in  one's 
complement  notation:  -3=1 ....  1100 .  Therefore,  -3  is 
even!  If  ODD  is  to  be  used  on  negative  numbers,  perhaps 
ODD(ABS(X))  should  be  substituted. 


Some  of  the  items  to  be  considered  in  transferrr ing  I/O  routines 
to  new  systems  include: 
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l  •  FILE  declarations  contain  unique  status  constants  to 

l  indicate  errors,  tape  marks  and  device  ready.  The 

;  number,  order,  and  meaning  of  these  constants  is 

l  guaranteed  to  vary. 


•  Device  names  are  assigned  by  the  compiler  implementor. 

•  Card  column  usage  is  system  dependent. 

•  Physical  device  characteristics  vary  greatly  (number 
of  tracks,  density,  parity). 

•  Record  size  restrictions  may  exist.  Some  systems 
override  FILE  declarations  and  make  their  own 
assignments . 
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•  Records  may  contain  system  reference  marks  such  as 
end-of-line,  carriage  control,  beginning  of  record, 
etc. 

•  Timing  controls  (one  manual  specifies  that  JOVIAL 
programmers  must  be  sure  that  40  milliseconds  elapses 
between  rewinds!) 

•  I/O  can  often  be  done  only  in  word  increments  making 
physical  record  length  a  variable. 

Core  size,  record  size,  instruction  set,  and  myriad  other  con¬ 
siderations  effect  the  method  of  compiler  implementation.  Be¬ 
cause  of  this,  compilers  will  be  forced  to  apply  restrictions 
on  programs  they  process.  Clearly,  no  well-defined  prediction 
of  these  restrictions  can  be  made  without  specific  knowledge 
of  the  particular  machine  to  be  utilized.  A  brief  summary  of 
some  of  the  more  commonly  restricted  items  and  representative 
size  limits  may  nonetheless  provide  some  insight  into  when 
JOVIAL  code  may  become  "uncompilable" .  This  in  turn  may  help 
the  JOVIAL  programmer  to  avoid  "way  out"  designs. 


Compiler  Implementation  Restraints 
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Item 


Restraint  Example 


3. 

Number  of  constants/ 
names 

2000 

UNIVAC  1108 

4. 

Nested  parentheses 

25 

UNIVAC  1108 

5. 

Nested  PROCEDURE  calls 

25 

UNIVAC  1108 

6. 

Number  of  PROCEDURE 
calls 

50C 

UNIVAC  1108 

7. 

Number  of  PROCEDURES 

250 

UNIVAC  1108 

8. 

Number  of  external 
references 

1025 

UNIVAC  1108 

9. 

Number  of  JOVIAL  signs 
per  statement 

200 

UNIVAC  1108 

10. 

Length  of  hollerith 
constants  (characters) 

250 

CDC  6000 

11. 

Length  of  a  name 
(characters) 

30 

CDC  6000 

12. 

Number  of  words  per 
table  entry 

32 

CDC  6000 

13. 

Nested  BEGIN-END 
brackets 

25 

CDC  6000 

14. 

Nested  IF  statements 

50 

CDC  6000 

15. 

Nested  IFEITH-ORIF 
statements 

20 

CDC  6000 

16. 

Nested  FUNCTION  calls 

20 

CDC  6000 

17. 

Time  between  I/O 
rewinds 

40ms 

Q7 

18. 

Number  of  DEFINE 
statements 

-75 

Q7 

19. 

Number  of  OVERLAY 
declarations 

128 

Q7 
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I  tern 

Restraint 

Example 

20. 

Number  of  variables 
per  OVERLAY 

32 

Q7 

21. 

Size  of  an  array 
(product  of  first  2 
dimensions ) 

2048 

Q7 

22. 

Size  of  index  in  a  FOR 
loop 

15  bits 

Q7 

23. 

Items  per  densely 
packed  TABLE 

50 

07 

24. 

COMPOOL  Restrictions 

ITEM  name 

STATES  name 

TABLE  name 

ENTRIES  per  TABLE 

4  characters 

3  characters 

3  characters 
9,999 

07 

25. 

Number  of  diagnostic 
messages  generated 

200 

CDC  6000 

26. 

Items  in  compiler  packed 
TABLE 

300 

CDC  6000 

27. 

Literals'  length 

8  characters 

D-825 

28. 

Only  the  first  six 
characters  of  names  are 
used  by  the  compiler 

H3118 

The  JOVIAL  programmer  can  write  his  program  as  a  collection  of 
small  routines  and  compile,  debug  and  modify  them  individually 
Assembling  these  routines  into  a  larger  program,  however,  in¬ 
volves  re-compilation  of  the  entire  set.  Further  modification 
or  correction  also  implies  total  recompilation  in  most  systems 
This  difficulty  could  seemingly  be  avoided  by  insertion  of 
checked-out  subprograms  into  the  system  library.  Since  most 
JOVIAL  compilers  produce  non-re locat able  code,  however,  this 
can  not  be  recommended  as  normal  practice. 

This  undesireable  restriction  evidently  has  led  a  few  pro¬ 
grammers  to  express  their  doubts  regarding  JOVIAL  modularity 
as  an  aid  to  program  transferability.  Some  feel  that  the 
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inability  to  update  individual  portions  may  inhibit  efforts  to 
modularize  machine  dependent  code.  Isolation  into  subprograms 
(which  may  introduce  "extra"  interface  bugs)  for  the  purpose  of 
facilitating  re-coding  may  increase  check-out  costs  since 
"good"  code  must  be  re-compiled  many  times  as  well. 

On  the  whole,  this  lack  of  independence  in  JOVIAL  seems  to  be 
more  of  a  deterrent  to  efficiency  than  to  portability.  The 
basic  elements  of  modular  design  are  nonetheless  available  to 
the  programmer.  Furthermore,  what  JOVIAL  lacxs  in  relation  to 
FORTRAN  independence  of  compilation,  it  may  make  up  for  in  its 
ability  to  utilize  the  macro-like  CLOSE  structure  within 
individual  routines.  Isolation  of  system  dependent  code  to 
PROCEDURES  (subroutines)  and  further  division  into  CLOSE  struc¬ 
tures  within  these  PROCEDURES  is  an  important  aid  to  transfer¬ 
able  design. 

Specification  of  general  input/output  routines  with  individual 
I/O  functions  defined  as  CLOSE  areas,  for  example,  might  enable 
this  highly  m.-chine  oriented  activity  to  become  a  series  of 
CLOSE  calls.  Hence  in  a  new  system,  much  of  the  structure  of 
the  I/O  function  could  be  retained  while  the  necessary  CLOSE’S 
are  re-coded. 

Another  feature  worth  mentioning  is  COMPOOL.  In  large  command 
and  control  applications,  data  referenced  in  several  programs 
need  be  declared  only  once.  Thus,  where  transfer  becomes 
necessary,  machine  dependent  declarations  must  be  rewritten 
only  once.  If  proper  parameterization  is  used,  a  relatively 
few  statements  need  ever  be  re-coded.  It  is  felt,  however, 
that  the  J3  Standard  should  specify  more  precisely  the  kind 
and  form  of  declarations  which  may  appear  in  COMPOOL. 

2.3.5  Parameterization 

The  most  predictable  aspect  of  large-scale  system  development 
is  change.  Modifications  to  the  requirements,  revisions  to  the 
specifications,  and  changes  in  design  or  programming  techniques 
all  result  in  changes  to  the  program  data.  Particularly  sus¬ 
ceptible  to  these  events  are  the  dimensions  of  data  structures, 
the  explicit  coding  of  numeric  data,  and  the  scaling,  packing 
and  precision  of  fixed  point  items.  If  specified  in  exact 
numeric  terms,  as  in  FORTRAN,  any  changes  in  these  characteris¬ 
tics  will  require  individual  analysis  and  modification  of  each 
of  several  references. 
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JOVIAL  presents  the  programmer  with  an  opportunity  to  isolate 
many  system  design  and  machine  dependent  features  into  a  rela¬ 
tively  small  number  of  statements.  Thus,  the  careful  program¬ 
mer  can  produce  a  large  percentage  of  transferable  code. 

This  facility  can  be  realized  through  judicious  use  of  compile 
time  parameterization.  On  the  other  hand,  overlooking  possi¬ 
bilities  of  using  parametric  representations  for  crucial  system 
oriented  factors  can  result  in  very  dependent  programs.  Like¬ 
wise,  poor  technique  or  over  proliferation  of  explicit  param¬ 
eters  can  also  be  a  hindrance.  For  instance,  a  parametric 
variable  for  the  number  of  records  on  an  output  tape  may  reduce 
re-coding  during  system  transfer,  while  explicit  delineation  of 
the  precision  required  for  specific  variables  (precision  is  a 
JOVIAL  parameter)  may  cause  extensive  recoding  of  ITEM 
declarations . 

Fortunately,  JOVIAL  is  flexible  in  this  area  and  even  parameters 
may  be  parameterized.  For  example,  DEFINE  a  variable  "PRECISE" 
to  be  "5".  Then  use  "PRECISE"  as  the  number  of  bits  to  the 
right  of  the  binary  point  in  a  particular  set  of  items.  The 
statements : 

DEFINE  VLENGTH  "16" 

DEFINE  PRECISE  "5" 

ITEM  X  VLENGTH  S  PRECISE 

would  generate  ITEM  X  16  S  5.  Of  course,  even  the  sign  designa¬ 
tion  "S"  should  be  parameterized  if  any  change  is  possible.  If 
a  machine  change  is  made  and  16  bits  are  no  linger  available, 
then  only  VLENGTH  may  need  to  be  changed.  All  ITEM  declara¬ 
tions  using  VLENGTH  would  be  left  alone.  These  simplistic 
techniques,  though  quite  effective,  seem  to  be  overlooked  or 
ignored  by  most  JOVIAL  programmers. 

Perhaps  the  most  crucial  area  with  regard  to  data  structure 
declarations  is  table  packing.  JOVIAL  allows  the  programmer 
to  specify  the  number  of  bits  allocated  to  each  ITEM  and  fur¬ 
ther  to  specify  which  bits  of  each  word  these  ITEMS  are  to 
occupy.  This  is  indeed  a  powerful  tool  which  could  produce 
highly  optimized  table  storage  allocations.  To  use  this 
ability  explicitly,  however,  is  to  hamper  attempts  at  trans¬ 
ferability.  A  new  machine  is  very  likely  to  have  a  differ¬ 
ent  word  size.  Hence,  all  table  packing  would  be  redone  by 
hand.  A  better  technique  may  be  to  parameterize  the  number 
of  bits  per  ITEM  and  allow  the  compiler  to  pack  the  data.  Most 
compilers  will  pack  from  left  to  right  as  ITEMS  are  encountered. 
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The  programmer  may  still  participate  in  storage  allocation  by 
listing  ITEMS  in  the  order  in  which  they  will  best  pack  into 
words.  Furthermore,  some  compilers  will  automatically  scan 
all  ITEM  declarations  and  choose  those  which  "fit"  together 
best  (use  most  number  of  bits  in  each  word) . 

The  following  is  a  summary  of  items  which  should  be  parameteri¬ 
zed  in  most  JOVIAL  programs: 

•  number  of  bits  per  variable 

•  number  of  fractional  bits  in  a  variable 

•  sign  specification 

•  packing  factor 

•  rounding  or  truncation 

•  maximum  number  of  entries  in  a  table 

•  number  of  words  per  entry 

•  range  of  values  for  a  variable 

•  array  size 

•  I/O  device  names 

•  number  of  records  per  file 

•  device  status  constants 

•  default  mode(s) 

The  last  entry  in  the  list  deserves  additional  mention.  The  Air 
Force  Standard  allows  for  the  presence  of  more  than  one  MODE 
directive  in  JOVIAL  programs.  Hence,  by  careful  ordering  of 
initialization  statements,  much  of  the  explicit  item  declara¬ 
tion  can  be  avoided.  For  instance,  if  a  program  is  to  have 
two  basic  types  of  variables,  say  16  bit  integers  and  16  bit 
fixed  point  with  5  fractional  bits,  two  MODE  declarations  could 
possibly  take  the  place  of  many  complex  ITEM  declarations. 
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Consider  the  example: 

MODE  I  16 
AB- 3+X A 


AZ  =  5 

MODE  A  16  S  5  P  5.1 
ITEM  XX 
ITEM  YY 
ITEM  ZZ 


All  variables  initialized  between  AB  and  AZ  would  be  integers 
and  all  variables  after  AZ  (XX, YY,...)  would  be  fixed  point 
with  initial  value  5.1.  Hence,  only  the  MODE  directive  may 
require  changing  during  system  transfer  (it  actually  should 
be  parameterized  also) . 

2.3.6  Code  Constraints 

Care  must  be  exercised  to  avoid  the  use  of  tricks  dependent  on 
particular  machine  or  system  idiosyncracies .  So  many  variations 
in  structure,  type  conversion  and  algorithm  implementation  are 
possible  that  use  of  specific  compiler  characteristics  can 
result  in  virtually  untransferable  code.  Worse  yet,  programs 
may  appear  machine  independent  while  producing  several  results 
when  executed  on  different  machines.  If  often  happens  that 
compilers  do  not  reject  certain  illegal  or  undefined  structures 
but  compile  them  instead,  giving  results  the  programmer 
"knows"  are  appropriate. 

It  is  universally  recommended  -that  programmers  avoid  exploita¬ 
tion  of  this  kind  of  special  knowledge.  There  is  no  guarantee 
that  a  new  version  of  the  compiler  will  exhibit  the  same  eccen¬ 
tricities  so  cleverly  discovered  by  a  programmer  who  may  no 
longer  be  present. 

Some  instances  where  this  type  of  coding  may  be  encountered 
are  listed  below. 
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•  Floating  point  comparisons  for  equality  nay  fail 
due  to  hardware  algorithm  inaccuracies  (absolute 
value  of  difference  should  be  substituted) . 

•  Binary  point  alignment  required  for  comparison  of 
fixed  and  integer  operands  may  cause  loss  of  high 
order  bits. 

•  Avoid  hollerith  comparisons  other  than  EQ,NQ  since  no 
collating  sequence  is  defined  generally. 

•  Unpredictable  results  may  result  from  FILE  declara¬ 
tions  within  PROCEDURES. 

•  Mixing  programmer  allocated  and  compiler  allocated 
(N,D,M)  packing  is  unpredictable  or  unallowed. 

•  Do  not  assume  that  the  value  of  a  function  is  passed  in 
the  accumulator,  register  0,  etc. 

•  Do  not  try  to  inhibit  rewind  by  overlaying  a  DUAL 
item  on  a  file  name,  OPEN  file  and  setting  DUAL  =  l. 

•  Do  not  expect  2N  to  be  implemented  by  a  shift  (it 
may  be  done  by  logorithms) . 

•  Avoid  use  of  mixed  type  expression  evaluations  such 
as  numeric=hollerith  which  expect  hollerith  to  be 
treated  as  a  straight  numeric  value  (no  conversion) 
or  hollerith-numeric  with  truncation  of  the  numeric. 

•  The  assumption  that  output  parameters  not  referenced 
in  a  particular  PROCEDURE  execution  (skipped)  main¬ 
tain  previous  values  (last  time  PROCEDURE  was  execu¬ 
ted)  is  sometimes  not  warranted. 

•  The  assumption  that  AX*B**C  is  evaluated  left  to 
right 

(Ab)C 

may  not  always  held  true. 

•  Shortening  status  constant  lists  by  specifying  too 
few  bits  and  assuming  remaining  constants  are 
ignored  is  bad  practice. 
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•  Automatic  code  conversion  between  hollerith  and  trans¬ 
mission  code  for  comparisons  may  not  occur. 

•  Entry  operations  on  TABLE  entries  of  varying  length 
may  produce  varying  results. 

•  The  assumption  that  indexing  is  performed  by  taking 
the  absolute  value  of  an  expression  is  not  warranted. 
For  example  X(9-17)=X(8)  in  some  implementations  and 
is  an  error  in  others. 

•  Although  convention  specifies  a  left  to  right  scan, 
some  compilers  could  conceivably  produce  different 
results  for  expressions  containing  functions  which 
modify  variables  ir.  the  expression.  For  example: 

A=A+SFUNC (A)*A  is  usually  A2=AQ+SFUNC (AQ) *A1 

where  Aq/Aj  and  A2  represent  3  states  of  the  variable 
"A"  which  is  altered  by  function  SFUNC.  Other  results 
could  exist  especially  if  optimization  of  code  is  per¬ 
formed  by  the  compiler.  (See  Appendix  A.) 

•  Do  not  assume  that  core  is  pre-set  by  the  system  (to  0 
or  other  values). 

•  Do  not  assume  that  the  NENT  of  a  variable  lengtii  table 
is  pre-set. 

2.3.7  Policy 

Many  of  the  recommendations  that  were  made  in  Section  2.2  are 
directly  applicable  to  JOVIAL  programs.  A  review  of  2.2.7 
should  prove  valuable  to  JOVIAL  programmers  as  well. 

Adherence  to  an  acceptable  standard  remains  the  most  necessary 
step  toward  assuring  program  and  programmer  transferability. 
Similarly,  careful  segmentation  of  programs  into  system 
oriented  and  machine  independent  modules  is  another  basic  goal. 
A  third  fundamental  principle,  parameterization,  is  especially 
important.  JOVIAL  has  distinct  advantages  over  other  higher 
level  languages  in  its  ability  to  parametrically  define  system 
dependent  attributes.  This  may  balance  the  seemingly  restric¬ 
tive  necessity  for  device  oriented  input/output  which  is  absent 
in  languages  such  as  FORTRAN. 
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These  three  concepts,  standardization,  modularity,  and  param¬ 
eterization  cannot  be  over  emphasized.  There  is  another  aspect 
of  JOVIAL,  however,  which  also  is  an  aid  to  transferability. 

The  lack  of  format  restrictions  and  the  ability  to  intermix 
comments  among  the  symbols  in  JOVIAL  statements  pro /ides  the 
ingenuous  programmer  an  opportunity  to  create  programs  which 
are  largely  self-documenting.  This  facilitates  easy  mainten¬ 
ance  and  revision.  A  policy  of  one  JOVIAL  statement  per  line 
and  meaningful  comments  on  the  same  card  where  possible  will 
help  maximize  the  readability  of  any  JOVIAL  routine. 

One  area  where  a  qualification  of  general  policy  regarding 
extensions  might  be  beneficial  is  external  PROCEDURES.  Most 
compilers  allow' only  internal  PROCEDURES  which  must  be  complied 
with  each  program  and  become  part  of  that  program.  External 
PROCEDURES,  which  are  compiled  separately,  are  very  useful  when 
a  routine  is  to  be  used  by  several  programs  that  operate  in 
core  memory  together.  With  this  facility,  only  one  copy  of 
the  routine  is  in  core  memory  and  each  program  refers  to  it 
either  by  an  external  PROCEDURE  declaration  or  by  COMPOOL 
definitions.  Although  this  is  not  a  standard  feature,  it  is 
quite  useful  and  does  not  seem  to  inhibit  future  transferability 
to  a  great  degree. 

There  are  also  features  in  JOVIAL  which  should  be  avoided  even 
though  they  are  included  in  the  Standard.  The  "DIRECT"  state¬ 
ment  is  an  example.  "DIRECT"  is  a  means  of  breaking  out  of 
JOVIAL  within  a  program  and  writing  instructions  in  the  basic 
assembly  language  of  the  target  computer  and  hence  is  generally 
non-transferable.  Obviously,  then,  DIRECT  code  should  be 
eliminated  or,  if  absolutely  necessary,  isolated,  simplified 
and  exhaustively  documented. 

Similarly,  the  specification  of  absolute  addresses  is  inflexible 
and  prohibits  relocation  of  data  or  program  blocks.  Relocation 
is  highly  desirable  in  that  it  allows  for  the  assembly  of  pro¬ 
grams  in  a  variety  of  ways  insensitive  to  the  operating  system 
environment.  Generally,  it  would  be  invalid  to  construct  pro¬ 
grams  that  assume  some  order  or  sequence  in  storage.  The 
possibility  exists  that  the  operating  system  may  segment 
arbitrarily  and  load  programs  into  whatever  space  is  available 
in  memory.  Furthermore,  in  a  time-sharing  environment  each 
"turn"  may  result  in  a  newly  allocated  memory  environment. 

Undoubtedly,  many  of  these  aspects  require  management  decisions: 
is  absolute  location  necessary;  how  much  direct  code  is  required; 
should  time-sharing  and  multi -programming  be  ruled  out;  etc. 
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Finally,  there  are  some  facets  of  JOVIAL  which  are  noticeably 
deficient.  The  precision  of  numeric  variables  (number  of  bits) 
for  instance,  cannot  exceed  the  number  of  magnitude  bits  in 
in  one  memory  word.  Frequently,  greater  precision  is  needed 
and  the  hardware  may  even  support  multiprecision  arithmetic. 
JOVIAL  seems  curiously  lackinq  in  this  area  considering  the 
myriad  of  sub-word  capabilities  that  do  exist.  Such  word  sisse 
dependence  may  seriously  inhibit  the  transfer  of  JOVIAL  pro¬ 
grams  to  "smaller"  machines. 
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2.4  ASSEMBLY  LANGUAGE  PROGRAMMING  FOR  TRANSFERABILITY 
2.4.1  Introduction 

It  is  in  assembly  level  programming  that  the  problems  associated 
with  program  transfer  become  the  most  acute  and  costly.  The 
least  significant  progress  made  in  regards  to  portability  has 
been  in  this  area.  Yet,  because  of  the  large  volume  of  program¬ 
ming  still  done  at  the  assembly  level,  the  greatest  requirements 
for  transferability  solutions  still  exist. 

Assembly  languages,  by  definition,  are  designed  for  a  particular 
machine  to  provide  some  way  of  specifying  every  function  and 
combination  of  functions  that  the  machine  may  perform.  Assembly 
languages  are  most  often  used  when  no  compiler  exists  for  the 
machine;  to  specify  functions  not  contained  in  higher  level 
languages;  to  avoid  some  highly  general  and  hence  inefficient 
code  generated  by  compilers;  or  to  avoid  interference  between 
the  compiler  output  and  the  desired  program. 

These  conditions  are  most  frequently  encountered  in  the  military 
and  scientific  environments  because  of  the  absolute  need  for 
maximum  program  efficiency,  because  many  special  purpose  compu¬ 
ters  (usually  not  possessing  FORTRAN  cr  other  higher  level 
compilers)  are  utilized,  and  because  of  the  frequent  computer 
changeovers  necessitated  by  new  weapon  systems. 

Generally,  when  a  programming  language  makes  reference  to  the 
unique  hardware  of  a  specific  computer  system  (sense  switches, 
drums,  discretes,  analog  I/O,  etc.),  it  is  not  possible  that 
programs  written  in  this  language  can  be  directly  transferred 
to  another  machine  unless  simulation  techniques  are  utilized. 
Inherent  characteristics  such  as  word  length,  internal  repre¬ 
sentations  (binary,  packed  decimal,  etc.),  and  character  size 
produce  similar  difficulties  when  machine  change  is  attempted. 
Word  sizes,  for  instance,  affect  the  results  of  numerical 
calculations,  the  storage  space  allocated  to  literal  data, 
address  sizes,  direct  value  magnitudes,  and  many  other  less 
tangible  aspects  of  the  problem  program.  Often,  even  transfers 
to  new  systems  on  the  same  machine  involve  problems  such  as 
assembler  instruction  repertoire  and  structure.  Apparently 
then,  there  is  no  way  to  write  assembly  code  to  make  it  auto¬ 
matically  transferable.  This  unfortunate  conclusion  has  caused 
many  programmers  to  label  assembly  language  transferability  as 
"impossible"  or  "ridiculous"  and  to  abandon  all  attempts  toward 
achieving  such  a  goal.  Hence,  some  programs  are  written  in 
a  manner  which  dictates  complete  re-design,  rc-coding,  and  re¬ 
check  out  for  each  new  system. 
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Clearly,  the  proDlem  is  one  of  degree.  There  are  techniques  for 
improving  the  transferability  of  assembly  language  programs. 

The  following  sections  will  deal  more  specifically  with  the 
factors  involved  and  will  present  examples  of  methods  currently 
utilized  by  groups  a  fively  involved  in  this  problem.  Perhaps 
as  these  concerned  organizations  develop  workable  techniques, 
skepticism  will  wane  and  more  individuals  will  come  forward 
with  meaningful  new  ways  to  increase  the  portability  of  "mach¬ 
ine  oriented"  programs. 

2.4.2  Assembly  Language  Justification 

There  are  many  applications  in  the  military,  systems  and  scien¬ 
tific  areas  where  assembly  level  programs  are  highly  economical 
and  unlikely  to  be  transferred  intact  (ideas  and  techniques  may 
be  transferable  while  specific  hardware  is  unique  and  short¬ 
term)  .  In  these  cases,  the  use  of  assembly  level  coding  needs 
no  justification.  In  other  more  general  applications,  however, 
serious  consideration  should  be  given  to  the  use  of  procedure 
and  problem  oriented  languages. 

The  non-professional  programmer  is  often  more  concerned  with 
expressing  and  solving  his  problem  rapidly  than  with  obtaining 
maximum  efficiency  from  the  machine  being  utilized.  For  this 
type  of  individual,  the  facility  by  wnich  he  can  write,  modify, 
understand,  and  de  istrate  his  program  is  of  foremost  import¬ 
ance.  In  many  in-  ices,  the  actual  code  may  be  used  as 
explanation  and  documentation  of  the  problem  being  solved. 

Before  such  a  program  is  implemented,  a  review  should  be  made 
of  the  justifications  most  commonly  given  for  the  use  of 
assembly  languages. 

•  No  higher  level  or  macro  language  is  available  for 
the  target  computer  and  the  cost/time  of  development 
of  such  a  tool  is  prohibitive. 

•  Acceptable  I/O  and  inner  loop  speeds  can  be  obtained 
in  no  other  way. 

•  The  problem  program  requires  code  complexity  which 
cannot  be  obtained  in  any  other  way. 

•  Insufficient  space  requires  extensive  bit  packing, 
machine  dependent  algorithms,  etc. 

©  A  level  of  security  must  be  provided  -  programs  must 
not  be  readily  discernable  by  "outsiders”. 
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®  Unique  machine  features  such  as  discretes,  sense 
switches,  and  interrupts  cannot  be  handled  in 
another  language. 

**»  Timing  and  instruction  counts  must  be  exactly 
calculable. 

•  Extensive  "patching"  of  assembled  code  may  be 
necessary. 

•  Dynamic  alternation  of  code  is  necessary  - 
execution  of  the  program  will  alter  the 
instructions  themselves. 

•  System  or  library  routines  with  heavy  usage  should 
be  as  efficient  as  possible. 

Many  of  the  items  listed  above  may  not  be  relevant  upon  further 
investigation.  Code  complexity  on  most  commercial  machines , 
for  instance,  is  seldom  an  excuse  since  FORTRAN  and  ALGOL  type 
languages  will  handle  a  large  percentage  of  these  problems. 
Similarly,  state-of-the-art  techniques  in  overlays,  paging, 
and  storage  allocation  have  alleviated  man^  space  problems. 
Assembly  language  "security"  has  really  never  been  valid  since 
obscure  code  can  always  be  overcome  by  an  experienced  program¬ 
mer  with  a  strong  desire  to  do  so.  Finally,  patched  code  and 
dynamic  source  alteration  are  considered  dubious  programming 
techniques  in  most  installations. 

There  are  still  instances  when  only  assembly  level  and  "machine 
oriented"  code  is  acceptable.  A  complex  time-sharing  system, 
an  8K  airborne  computer,  a  9-bit  process  control  monitor  and 
myriad  other  applications  require  peak  efficiencies  in  time 
and  space  utilization  usually  obtained  only  by  assembly  level 
languages . 

It  is  in  this  area,  programs  that  must  be  coded  at  the  machine 
level,  that  efforts  for  increased  transferability  are  most 
needed.  Subsequent  sections  will  present  suggestions  for  the 
improvement  of  this  situation. 


2.4.3  Hardware  Design  Constraints 


The  computer  designer  has  considerable  freedom  of  choice  in 
determining  the  final  configuration  of  a  computer  system.  The 
assembly  languages  ultimately  provided  for  use  of  these  systems 
will  be  largely  pre-determined  and  severely  constrained  by  the 
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array  of  hardware  features  selected.  It  follows,  then,  that 
assembly  language  transferability  is  directly  effected  by  basic 
hardware  compatibility. 

From  a  portability  standpoint,  one  of  the  most  difficult  mach¬ 
ine  dependent  areas  to  overcome  is  that  of  the  computer's  regis¬ 
ter  architecture.  This  is  especially  'true,  when  fully  effective 
employment  of  the  computer's  particular  register  scheme  is  to 
occur.  Currently,  common  computers  range  from  having  16  general 
registers  to  one  very  limited  register.  This  wide  variance  is 
further  compounded  by  difficulties  arising  from  differing  regis¬ 
ter  arrangements.  Possibilities  involved  are:  operations  be¬ 
tween  general  registers  or  registers  and  memory,  transfers  of 
data  between  registers  of  different  lengths,  registers  altered 
by  external  devices,  registers  that  count  up,  down  or  both, 
registers  with  distinct  sign  bits,  and  more. 

Another  basic  incompatibility  that  must  be  dealt  with  is  the 
current  wide  variety  of  addressing  schemes  available.  Some  of 
the  more  common  methods  include  direct,  base,  relative,  indirect 
and  indexed.  Virtually  every  combination  of  these  types  has 
been  incorporated  by  some  computer  manufacturer.  Even  within 
a  particular  address  type,  there  may  be  wide  variations.  For 
example,  different  quantity  of  index  registers,  single  level  or 
multiple  level  indirect,  pre-indexing,  post-indexing,  etc.  This 
area  represents  one  of  the  most  difficult  transferability  stum¬ 
bling  blocks  since  taking  full  advantage  of  existing  addressing 
schemes  is  fundamental  to  program  efficiency.  Virtually  all 
areas  of  a  computer  program  will  be  effected. 

An  additional  factor  that  often  hampers  the  transfer  of  programs 
is  the  computer's  internal  method  for  representing  negative 
numbers.  If  the  computer  uses  a  binary  number  system  internally, 
number  representation  may  be  2's  complement,  l’s  complement,  or 
magnitude  and  sign;  similar  choices  may  be  made  if  the  computer 
is  decimal  or  byte  oriented.  One  particular  problem  that  arises 
is  that  some  programs  may  make  use  of  a  negative  zero,  which 
does  not  exist  in  a  2's  complement  number  system.  Similarly, 
a  programmer  may  use  a  negative  constant  as  a  logical  mask. 

When  transferring  to  another  computer  with  a  different  negative 
representation,  the  mask  usage  may  cause  an  error. 

In  yet  another  area,  control  of  peripheral  dev.-jes,  both  the 
design  and  use  of  assembly  languages  necessarily  effects  the 
original  configuration  of  hardware.  The  equipment  associated 
with  a  computer  may  vary  widely  in  speed,  capacity  and  mode  of 
use.  A  disk  memory  may  have  fixed  or  multiple  heads.  Magnetic 
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tape  units  may  be  seven  or  nine  track,  recording  may  be  of 
different  densities  and  speeds,  and  the  tape  unit  may  read  only 
forward  or  may  read  both  forward  and  backward.  The  number  of 
printer  columns  may  differ  from  one  installation  to  inother,  or 
perhaps  an  output  device  may  be  capabje  of  both  printing  and 
pictorial  output.  Input-output  device  priorities  may  be  hard¬ 
ware  or  software  determined.  Communication  with  peripheral 
devices  may  be  by  means  of  busses,  or  direct  wiring;  in  one  case 
each  device  must  be  addressed  and  connected  before  data  trans¬ 
fer  occurs,  in  the  other,  these  steps  may  be  omitted.  Input- 
output  communications  may  be  through  the  central  processor, 
through  a  controller  that  steals  memory  cycles,  or  by  a  satellite 
computer  that  accesses  the  same  memory  devices. 

In  the  very  worst  case,  unconventional  hardware  may  be  intro¬ 
duced,  with  the  result  that  either  program  libraries  must  be 
rewritten  or  else  the  capabilities  of  the  computer  will  be  very 
inefficiently  employed.  Unconventional  hardware  that  may  have 
to  be  considered  includes  microprogramming,  associative  memor¬ 
ies,  parallel  processors,  and  pipeline  processors.  Micro¬ 
programming  capabilities  may  permit  the  user  to  configure 
instruction  codes  to  his  own  needs.  Associative  memories  may 
greatly  affect  look-up  or  search  procedures.  Parallel  process¬ 
ing,  exemplified  by  Illiac  IV,  requires  an  entirely  different 
type  of  operation.  A  computer  with  a  software-alterable  pipe¬ 
line  processing  system  would  necessitate  new  programming  and 
system  operation  techniques  for  effective  use. 

After  a  brief  investigation  into  some  of  the  factors  involved 
in  the  design  and  use  of  an  assembly  language,  it  becomes  clear 
that  many  computer  programs  cannot  be  effectively  transferred 
without  massive  re-coding.  This,  of  course,  is  without  even 
considering  basic  differences  in  language  mnemonics  and  formats. 
Upon  elimination  of  the  more  extreme  computer  architectures,  a 
list  of  basic  machine  differences  may  be  compiled. 

•  Instruction  repertoires  -  number,  type  and  format 

•  Word  size 

•  Page  size 

•  Core  size 

•  Address  size 

•  Character  and  byte  size 
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•  Register  architecture  -  general,  base,  index 

•  Cycle  time 

•  Input/output  characteristics 

•  Interrupt  types,  mechanisms  and  priorities 

•  Internal  number  representation  -  binary,  packed 
decimal,  etc. 

•  Floating  point  format 

•  Arithmetic  -  fixed  point  fractional,  integer,  etc. 

•  Multiplication  and  division  characteristics  -  double, 
single,  remainder,  etc. 

•  Condition  codes,  overflows,  sense  lights,  etc. 

•  Logical  and  magnitude  operations 

•  Half,  full,  and  double  length  instructions 

•  Half,  full,  variable  length  data  reference 
capabilities 

•  Character  set 

•  Negative  number  representation 

m  Shifts  -  sign  excluded,  sign  propagated,  single, 
double,  variable  length,  arithmetic,  logical,  rota¬ 
tional,  etc. 

•  Peripherals  -  speed,  capacity,  modes  of  use. 

•  Addressing  -  direct,  base-displacement,  indirect, 
relative,  indexed,  etc. 

•  Memory  -  scratchpad,  drum,  core,  ROM,  etc. 

This  list  should  be  consulted  (and  augmented)  whenever  a  sys¬ 
tem  transfer  is  anticipated.  In  the  event  a  new  computer  is  to 
be  obtained,  a  quantitative  analysis  of  architectural  differ¬ 
ences  weighted  by  their  effect  on  program  library  transferability 
could  be  compiled  for  each  prospective  machine.  This  in  turn 
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may  be  weighed  against  the  cost,  power  and  general  applicability 
of  each  candidate.  Unfortunately,  these  weighing  factors  will 
vary  considerably  with  the  applications  and  machines  involved. 
Hence,  they  cannot  be  rigidly  defined  for  all  machines  in 
general . 

2.4.4  Parameterization 

In  the  previous  section,  a  number  of  machine  dependent  charac¬ 
teristics  were  identified  as  probable  hindrances  to  the  transfer 
or  assembly  language  programs.  Fortunately,  some  of  these 
variables  can  be  effectively  handled  by  parameterization  tech¬ 
niques  . 

Frequently,  an  assembly  level  statement  will  be  non-transf erable 
simply  because  the  programmer  unnecessarily  utilized  machine- 
oriented  knowledge  in  performing  an  application-oriented  func¬ 
tion.  For  instance,  to  left  justify  a  character  in  a  register 
(contending  that  this  is  a  reasonable  thing  to  do  independent 
of  a  particular  machine)  he  may  have  coded: 

SHIFT, LEFT  REGO,30 

Embedded  in  this  statement  is  a  knowledge  of  the  register  (REGO) 
and  character  size  (say  36  and  6  bits  respectively) .  A  more 
transferable  approach  would  be  to  write: 

SHIFT, LEFT  REGO ,WDSJ ZE-CSIZE 

where  WDSIZE  and  CSI2E  had  been  parametrically  defined  (via  an 
"EQU")  at  the  beginning  of  the  program. 

Almost  all  programmers  have  been  asked  to  modify  certain  aspects 
of  their  programs  as  a  result  of  changes  to  specifications  and 
requirements  of  the  problem  being  solved  or  function  being  per¬ 
formed.  These  programmers  rapidly  learned  to  plan  ahead  for 
such  events  by  parameterizing  application  dependent  attributes 
such  as  table  sizes,  number  of  fields  on  a  card,  etc.  Few  will 
disagree  that  this  practice  has  saved  considerable  effort  when 
changes  are  finally  requested.  The  same  techniques  should  be 
encouraged  for  computer-dependent  aspects  of  assembly  language 
programs . 

Depending  on  the  application,  many  of  the  following  machine 
features  will  appear  in  the  code  and  thus  will  require 
parameterization . 
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•  condition  codes 

•  characters  per  word 
«  word  size 

®  character  size  -  bits  per  character 

•  address  size 

•  page  size 

•  right  halfword  (mask) 

•  left  halfword  (mask) 

•  character  mask 

•  character  set 

•  registers 

•  parity  (0  for  even,  1  for  odd) 

•  -1  or  other  basic  negative  number 

•  sense  devices  (switches,  lights) 

•  buffer  sizes 

•  record  sizes 

•  I/O  devices 

•  origins  (instruction  counter  values) 

•  key  bit  or  character  positions  (for  packed  data) 

•  file  marks 

2.4,5  General  Coding  Techniques 

The  previous  section  contained  a  list  of  machine  dependent  items 
which  are  the  most  likely  candidates  for  parameterization.  In 
conjunction  with  this  list,  a  set  of  general  assembly  language 
coding  guidelines  has  been  prepared.  Many  of  the  suggestions 
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are  based  on  composite  characteristics  of  the  currently  most 
popular  machines. 

•  When  defini\g  condensed  data  structures,  no  more  than 
n  bits  of  information  should  be  packed  into  a  single 
word,  when  n  is  the  minimal  word  size  of  a  computer 
to  which  the  programs  might  be  transferred. 

•  No  immediate  (direct)  values  should  exceed  50%  of 
the  minimum  word  size  or  be  relocatable. 

•  All  shift  instructions  that  are  justifying  or  posi¬ 
tioning  data  should  use  word-size  and  character-si z_ 
parameters. 

•  Data  should  be  declared  on  word  boundaries. 

•  Logical  masks  should  not  be  defined  as  negative 
numbers. 

•  Data  constants  and  EQU  parameters  defined  at  a 
definite  place  in  the  program  should  be  used  in 
place  of  literals. 

•  Address  and  instruction  modifications  during  execu¬ 
tion  (dynamic  code  replacement)  should  be  avoided. 

•  Test  characters  and  values  against  data  constants 
defined  earlier. 

•  Use  symbolic  names  for  all  hardware  such  as  registers, 
indexes,  etc. 

•  Avoid  relative  code  such  as: 

JUMP  $+5 

If  necessary  for  some  reason,  parameterize  the  add¬ 
resses  as  $+N5.  This  is  especially  important  in 
transferring  between  byte  address  and  word  address 
machines . 

•  Explicitly  state  each  equation,  function,  or  decision 
tree  in  comments. 

•  List  all  system  calls,  their  purposes  and  locations. 
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•  Avoid  complex  floating  point  manipulations. 

•  Note  any  bulk  I/O  non-standard  usage. 

•  Limit  printed  output  fc  120  characters  per  line. 

•  Use  data  masks  to  extract  sub-units  of  a  word  (left 
half-word,  second  character,  etc.). 

•  Avoid  tests  which  are  sign  and  arithmetic  dependent. 

For  example,  whenever  possible  use  "transfer  on  non¬ 
zero"  rather  than  "transfer  on  plus". 

•  Do  not  assume  pre-ini tialized  memory. 

•  Avoid  sign  manipulation  such  as  "set  sign  plus"  or 
"complement  and  add"  rather  than  "subtract". 

•  Use  macros  or  subroutines  for  double  precision  opera¬ 
tions  . 

•  Don't  depend  on  absolute  core  location  knowledge  - 
assume  relocatability . 

•  Avoid  indexed  -  indirect  addressina. 

•  Use  macros  or  subroutines  for  I/O  operations. 

•  Note  micro  coded  instructions  -  relying  heavily  on  a 
micro  cobed  search  (B5500)  or  decimal  (IBM  360) 
instruction  may  cause  poor  results  when  transferring 
to  a  new  machine  without  these  facilities. 

•  Be  familiar  with  hardware  trends.  In  particular, 
recognize  engineer  designed  and  programmer  designed 
machines.  For  instance,  code  may  be  transferred 
more  readily  between  two  machines  that  are  programmer 
oriented . 

•  Take  advantage  of  special  timing  knowledge  (external 
device,  instruction  execution,  etc.;  only  if  necessary. 

•  Try  to  avoid  complex  machine  oriented  scaling. 

•  Prepare  a  section  (module)  frequency  chart.  This  will 
aid  in  general  understanding  of  your  program  and  may 
be  used  to  estimate  the  time/cost  effects  of  transfer 
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to  new  machines.  Bascially,  this  chart  should 
contain: 

.  function  performed 
.  section  of  module  involved 
.  estimated  frequency  per  run 
.  estimated  time  per  iteration 
.  estimated  percent  of  total  run  time 

•  Prepare  a  register  usage  chart.  This  is  of  great  bene¬ 
fit  to  other  programmers  who  may  be  required  to  alter 
your  program  and  it  also  helps  to  insure  that  the 
minimum  number  of  registers  is  used  at  all  times.  This 
chart  is  usually  subdivided  by  program  section  or  sub¬ 
routine  and  register.  Each  register  in  the  module  is 
then  flagged  by  symbols  indicating  its  use.  For 
example, 

S  -  special  purpose 
M  -  multi-purpose 
L  -  loop  control 
X  -  index 
G  -  global 
A  -  arithmetic 
H  -  logical  masks 
F  -  shifting 

Additional  guidelines  of  a  more  complex  nature  will  be  presented 
in  Sections  2.4.6,  Modularity,  and  2.4.7,  Macro  Coding. 


2.4.6  Modularity 


It  was  pointed  out  in  the  discussion  of  higher  level  languages 
that  the  ability  to  divide  machine  dependent  and  independent 
attributes  into  separate  entities  greatly  enhances  the  trans¬ 
ferability  of  computer  programs.  This  concept  also  pertains  to 
assembly  level  coding.  Programs  can  be  modularized  so  as  to 
render  the  environment  of  relatively  independent  sections  in¬ 
variant  while  identifying  and  isolating  the  more  machine 
oriented  areas. 


Hence,  program  functions  which  will  require  a  great  deal  of  pro¬ 
grammer  attention  upon  transfer  should  be  isolated  in  distinct 
modules.  These  modules,  in  turn,  should  be  organized  and  docu¬ 
mented  such  that  they  can  be  worked  on  with  little  reference  to, 
or  interference  with,  other  modules.  The  rest  of  the  program 
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can  then  be  automatically  transferred,  converted  or  re-coded 
with  less  effort. 

Individual  assembly  of  modules  further  aids  the  check  out  of 
transferred  programs.  Assembly  languages  are  usually  flexible 
in  this  regard,  although  it  is  generally  necessary  to  distribute 
symbol  definitions  among  modules  by  pre-loading  the  assembly 
table  or  by  load- time  resolution. 

A  theoretical  modularity  design  specific  enough  to  be  effective 
yet  general  enough  to  cover  a  wide  range  of  application/sys¬ 
tems  is  a  somewhat  abstract  concept.  A  review  of  assembly 
language  programs,  however,  indicates  many  common  features.  The 
following  outline,  which  reflects  these  similarities,  is  pro¬ 
posed  as  a  basis  for  the  modularization  of  assembly  level 
programs.  Although  it  seems  functional  in  nature,  this  design 
serves  to  separate  highly  system  dependent  code  (inner  loop, 
interrupts)  from  less  machine  oriented  activities  (main  body, 
data  generation^ . 

Modular  Design  of  Assembly  Programs 

•  Main  Control 

.  Prologue 
.  Main  Body 
.  Epilogue 

•  Initialization 

•  Data  Generation 

•  Outer  Loop 

•  Inner  Loop 

•  Output  Data  Routine 

•  Clean-Up 

•  Interrupts 

•  Error  Handling 

The  purpose  and  content  of  these  sections  is  defined  on  the 
following  pages: 
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The  main  control  section  is  intended  to  be  the  basis  for  the 
transfer  of  the  program.  It  must  contain  sufficient  informa¬ 
tion  to  allow  other  programmers  to  perform  the  re-coding, 
substitution  of  parameters,  and  other  procedures  necessary  to 
update  the  program  for  the  new  machine.  In  particular,  the  pro 
logue  should  include: 

•  storage  layout 

•  program  modules 

•  section  frequencies 

•  constants  and  masks 

s 

•  register  definitions,  macros,  universal  instruction 
definitions  (see  2.4.7) 

•  character  set 

•  common  storage 

•  documentation  as  to  purpose  of  the  program 

•  comments  regarding  any  of  the  above  items  which  occur 
in  other  sections  and  the  relationships  involved 

The  main  body  consists  of  the  main  control  logic  and  calcula¬ 
tions.  It  will  call  upon  the  other  sections  including  the 
system  and  termination  procedures. 

•  main  program 

•  calls  to  routines 

•  system  service  requests 

•  exit 

The  epilogue  will  summarize  the  machine  and  program  character 
istics  not  mentioned  elsewhere.  Generally,  this  will  include 

•  miscellaneous  machine  characteristics 

•  code  anomolies 

•  system  requirements 
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•  eccentricities,  idiosyncracies ,  tricks,  etc. 

•  pointers  to  key  areas  where  word,  byte  and  other 
machine  factors  are  of  special  importance 

The  initialization  section  sets  up  starting  program  data, 
initializes  memory,  restart  parameters,  path  setting  informa¬ 
tion,  and  other  factors  not  handled  in  the  prologue. 

The  data  generation  section  either  generates  (via  program  algo¬ 
rithms)  or  inputs  data  to  be  used  in  other  sections.  This  data 
should  be  well  insulated  from  external  devices.  Hence,  it  must 
be  presented  in  a  format  which  is  source  device  independent. 
Macros  or,  if  possible,  higher  level  languages  can  be  utilized 
in  many  instances. 

The  outer  loop  section  is  somewhat  artificial  in  that  its  pri¬ 
mary  function  is  to  control  the  inner  loop.  It  may  be  thought 
of  as  an  interface  between  the  main  body  (application  oriented) 
and  the  inner  loop  (specific  machine  functions  necessary  to 
perform  calculations) . 

The  inner  loop  can  be  defined  as  those  machine  specific  func¬ 
tions  which  must  be  re-coded  for  every  machine.  Candidates 
for  this  module (s)  would  be:  functions  which  are  very  critical 
in  terms  of  time,  space,  or  accuracy;  algorithms  which  are 
very  difficult  to  parameterize  but  which  utilize  hardware 
characteristics;  micro-coded  instruction  routines;  and  unusual 
external  device  interfaces.  Elements  which  are  placed  in  the 
inner  loop  are  often  responsible  for  the  choice  of  assembly 
language  as  the  implementation  tool.  By  definition,  the  inner 
loop  will  probably  have  to  be  re-organized  and  re-coded  for 
every  machine.  For  this  reason,  it  must  be  minimized  by  full 
utilization  of  parametric  and  macro  coding  techniques.  Similar¬ 
ly,  the  inner  loop  must  be  carefully  commented  as  to  purpose, 
precisions,  frequencies,  machine  oriented  techniques  (dynamic 
word  modification,  etc.),  and  application  functions  included. 

The  output  data  routing  section  will  be  the  counterpart  to  the 
data  generating  section.  It  will  convert  data  from  a  basically 
machine  independent  format  to  device  oriented  structures  and 
perform  the  actual  output  commands.  It  may  include  preparation 
of  data  for  handling  by  other  programs  written  in  different 
languages. 

The  clean-up  section  will  prepare  and  make  dumps  for  future 
restarts  if  necessary.  It  will  also  act  as  the  counterpart 
to  the  initialization  section. 
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The  interrupt  section  will  detect  and  process  all  interrupts 
(I/O,  system,  error,  etc.).  It  may  pass  control  to  the  error 
section  for  handling  of  recovery  procedures  if  necessary. 

This  section  is  usually  very  machine  oriented  and  may  require 
extensive  re-organization  during  system  transfer. 

The  error  section  will  handle  problems  encountered  in  other 
sections  and  may  be  further  sub-divided  into  software  and 
hardware  errors.  With  a  great  deal  of  care,  this  section  can 
be  made  largely  general  in  nature  and  will  require  varying 
degrees  of  re-work. 

Of  course,  in  practice  it  is  often  difficult  to  distinguish 
and  separate  machine  dependent  attributes.  Especially  in 
assembly  language,  machine  independence  is  often  only  a  matter 
of  degree.  Nonetheless,  some  efforts  at  modular  design,  when 
combined  with  parameterization  and  macro  coding  techniques, 
can  produce  noticeable  reductions  in  the  costs  of  program 
transfer. 

2.4.7  Macro  Coding 

Many  of  the  transferability  advantages  of  higher  level  languages 
can  be  realized  with  the  use  of  macro  concepts.  To  the  extent 
that  existing  macro  assemblers  allow  for  a  common  invocation 
format,  a  program  written  as  a  sequence  of  macro  instructions 
can  be  transferred  to  machines  of  similar  architecture  by 
Simply  rewriting  macro  definitions.  The  costs  involved  in 
program  transfer  can  be  greatly  reduced  in  this  manner.  In 
many  instances,  programs  may  be  coded  which  are  nearly  as 
transferable  as  those  written  in  higher  level  languages.  Very 
little  operating  efficiency  is  sacrificed  since  the  macro 
definitions  are  machine  oriented. 

For  example,  a  triple  address  computer  may  be  utilized  with 
the  macro: 

ADD  AUGEND  ADDEND  RESULT 

In  one  machine  this  may  expand  to: 

CLA  AUGEND 
ADD  ADDEND 
STO  RESULT 
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In  another  computer  the  result  could  be: 

L  Rl, AUGEND 

A  Rl, ADDEND 

ST  Rl , RESULT 

Hence,  simple  macros  may  be  developed  which  can  be  used  as 
higher  level  language  statements  and  which  display  noticeable 
machine  independent  characteristics. 

There  are  many  difficulties  to  be  overcome  in  a  macro  processor 
approach,  however.  Assembler  implementations  cover  a  wide 
range  of  capabilities.  Some  are  widely  employed  because  of 
their  power  while  others  are  so  weak  as  to  be  virtually  useless. 

The  most  reasonable  solution  to  this  non-standardization  prob¬ 
lem  is  the  development  of  an  essentially  machine  independent 
assembler.  This  software  should  include  powerful  macro  capa¬ 
bilities  and  extensive  target  computer  parameterization 
facilities.  Such  products,  usually  called  meta  assemblers, 
do  currently  exist  (for  example,  international  Computer  Sys¬ 
tems'  DUAL  meta  assembler  is  operational  on  numerous  host 
computers  generating  code  for  a  variety  of  targets) . 

A  meta  assembler  allows  for  the  description  of  pertinent  tar¬ 
get  computer  characteristics  including  the  symbolic  assembly 
format  of  the  instructions.  The  macro  facilities  include  means 
of  conditionally  generating  different  sequences  of  code  based 
on  the  arguments  of  the  calling  lines.  With  such  a  tool, 
assembly  languages  may  be  developed  which  are  capable  of 
producing  object  code  for  a  wide  variety  of  machines.  Addi¬ 
tional  benefits  could  be  realized  if  the  meta  assembler  itself 
was  readily  transferable  (via  self-assembly  and  interpretive 
techniques) . 

Some  of  the  factors  which  are  provided  by  the  user  to  the  meta 
assembler  include: 

•  core  size 

•  word  size 

•  character  size 

•  character  set 

•  floating  point  format 


•  fixed  point  format 

•  negative  number  representation 

•  address  size 

•  page  size 

•  base  registers 

•  object  structures 

•  command  mnemonics  and  formats 

Usually,  this  information  can  be  maintained  in  libraries  along 
with  the  macro  definitions. 

Cross-assembly  and  source  to  source  translation  are  additional 
transferability  applications  inherent  in  a  meta  assembler.  The 
commonly  used  conversion  technique  of  translation,  for  instance, 
can  be  implemented  by  macros.  Source  input  language  mnemonics 
become  macro  names  while  the  expansions  consist  of  equivalent 
output  language  statements.  Any  unresolvable  ambiguities  can 
be  readily  flagged  as  part  of  the  macro  process.  Similarly, 
when  two  or  more  input  statements  must  be  combined,  the  assem¬ 
bler  can  allow  for  saving  input  lines  in  working  parameter 
lists . 

Assuming  the  availability  of  such  a  tool,  plans  may  be  made 
for  the  development  of  a  "universal"  assembly  language  for  use 
on  a  variety  of  machines  but  maintaining  machine  oriented  capa¬ 
bilities.  This  concept  of  course,  is  complicated  by  the  fan¬ 
tastic  variety  of  computer  architectures  presently  in  use.  The 
definition  of  a  universal  assembly  language  must  include  meth¬ 
ods  of  defining  register  implementation,  addressing  schemes, 
and  less  salient  features  of  the  computer  architecture.  Other¬ 
wise,  highly  inefficient  and  lengthy  programs  may  result. 

It  is  difficult  to  imagine  an  assembly  language  designed  for 
efficient  use  of  every  machine  in  existence.  Since  many  pro¬ 
grams  would  not  be  coded  in  assembly  languages  if  efficiency 
was  not  of  primary  concern,  this  facet  of  the  problem  cannot 
be  ignored. 

Keeping  these  conflicting  factors  in  mind,  the  most  acceptable 
compromise  seems  to  be  the  maximum  utilization  of  the  original 
target  computer's  architecture .  The  degree  of  efficiency  of 
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code  produced  for  new  targets  must  become  a  function  of  the 
"likeness"  of  the  new  machine.  This  is  entirely  reasonable 
since  one  of  the  factors  involved  in  the  purchase  of  new  equip¬ 
ment  must  be  its  compatibility  with  existing  ar.d  future  hard¬ 
ware  implementations. 

A  most  important  facet  of  the  development  of  a  universal  assem¬ 
bly  language  is  the  efficient  use  of  the  current  register- 
address  schemes  in  a  manner  readily  adaptable  to  other  computers. 
As  yet,  no  solutions  have  been  presented  which  promise  to 
completely  satisfy  this  requirement.  One  possible  approach, 
however,  is  described  below. 

•  A  base  register  machine  is  assumed.  The  assembler 
should  do  as  much  of  the  base-displacement  manipu¬ 
lation  as  possible  and  the  programmer  should  use 
symbolic  addressing.  If  the  target  computer  as 
directly  addressable,  the  base  address  defaults  to 
0. 

•  The  user  will  declare  registers  and  code  with  a 
particular  architecture  in  mind.  For  example,  in 
a  machine  with  16  general  registers,  instructions 
such  as  the  following  may  occur. 

ADD  R1  R2  R2 

If  this  implies  "add  the  contents  of  register  R2  to 
register  Rl  and  leave  the  result  in  R2" ,  it  assumes 
a  knowledge  of  the  previous  contents  of  Rl  and  R2 
and  makes  efficient  use  of  the  machine's  architecture. 

In  a  single  accumulator  (R0)  machine,  the  same  state¬ 
ment  might  be  processed  (by  the  ADD  macro)  as  "add  the 
contents  of  memory  location  Rl  to  the  contents  of 
memory  location  R2  and  store  in  memory  location  R2" . 

It  follows,  then,  that  the  efficiency  of  the  program 
with  respect  to  machine  design  is  directly  related  to 
the  "likeness"  of  the  computers  involved.  Note  that 
upon  transfer  of  such  a  program,  a  new  register 
declaration  and  set  of  macros  must  be  generated. 

•  Regi'ters  can  be  used  as  lor  arithmetic,  shifting, 
indexing,  and  other  "normal"  operataons. 

•  Registers  and  memory  should  be  considered  inter¬ 
changeable  for  most  instructions. 
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•  Indirect  addressing  and  indexing  can  be  used  for 
address  modification. 

•  A  basic  address  operand  format  of: 

"register , index 
*address , index 

is  assumed  where  *  indicates  indirect  addressing. 

•  The  basic  instruction  format  is: 

INSTRUCTION, m  a  b  c 

where  a  and  b  are  inputs,  c  is  the  result,  and  m  is 
an  instruction  modifier  (see  condition  codes) .  With 
some  instructions,  a,  b,  c  and  m  will  be  optional, 
a,  b,  c,  will  be  considered  addresses  or  direct 
values  where  appropriate. 

•  Condition  codes  will  be  handled  by  the  macro  pro¬ 
cessor  such  that  mnemonics  may  be  substituted  for 
actual  values.  For  example,  assuming  X,  Y,  and  Z 
are  addresses  and  V  is  a  value, 

LOAD  X 

COMPARE  Y 

BRANCH-ON-CONDITION  V , Z 

may  be  coded  as : 

CW,GT  X  Y  Z 

which  reads  "compare  words  X  and  Y  and  branch  to  Z 
if  X  is  greater". 

•  All  macro  (universal  assembly  language  command) 
mnemonics  will  contain  a  $  (or  any  special  character) 
to  avoid  conflicts  with  actual  machine  instructions. 

With  these  ground  rules  in  mind,  a  set  of  universal  assembly 
language  commands  can  be  formulated.  In  the  following  instruc¬ 
tion  set  definition,  a  few  descriptive  symbols  are  used. 

•  The  "Type"  column  contains  four  items;  A,I,R,  and  M. 
These  subcolumns  indicate  some  of  the  characteristics 
of  each  instruction.  The  column  explanations  are 

as  follows: 


A  -  The  number  of  address  type  operands  associated 
with  the  instruction. 

I  -  A  check  in  this  column  indicates  that  an  imme¬ 
diate  value  is  presented  as  part  of  the  instruction. 

R  -  A  check  in  this  column  indicates  a  relational  is 
presented  as  part  of  the  instruction.  The  rela- 
tionais  that  may  be  associated  with  the  "compare" 
and  "jump  if  index"  commands  are: 

EQ  -  Equal 

GT  -  Greater  than 

GQ  -  Greater  than  or  equal  to 

LT  -  Less  than 

LQ  -  Less  than  or  equal  to 

NQ  -  Not.  equal 

The  relationals;  that  may  be  associated  with  the 
JUMP  command  are : 

P  -  Positive 
N  -  Negative 
V  -  Overflow 
Z  -  Zero 
NZ  -  Non  zero 

M  -  A  check  in  this  column  indicates  that  the  number  of 
words,  bytes,  or  bits  operated  upon  is  supplied 
as  part  of  the  instruction.  For  example, 

MW$ ,3  A  B 

is  interpreted  as  “move  3  words  from  A  to  B" . 

•  In  the  function  column,  a,  b,  and  c  are  used  to  repre¬ 
sent  the  operands  involved  in  the  command.  The  letter 
v  is  used  to  represent  immediate  values. 
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UNIVERSAL  COMMAND  REPERTOIRE 


COMMAND 

TYPE 

FUNCTION 

Mnemonic 

"English-like" 

AIR 

_M 

Arithmetic: 

(Fixed  Point) 

A$ 

ADD? 

3 

b  +  a  —  c 

s$ 

SUBTRACT? 

3 

b  -  a  —  c 

M? 

MULTIPLY? 

3 

b  x  a  —  c 

D$ 

DIVIDE? 

3 

b  -f  a  —  -c 
remainder  —  c  +  1 

AV? 

ADD?VALUE 

2  * 

a  +  v  —  b 

SV$ 

SUBTRACT?VALUE 

2  * 

a  -  v  —  b 

MV? 

MULTIPLY? VALUE 

2  * 

a  x  v  —  b 

DV$ 

DIVIDE? VALUE 

2  * 

a  4-  v  —  b 
remainder  —  b  +  1 

Loqical : 

AND? 

and$logical 

3 

a  .  b  —  c 

ORE? 

OR$EXCLUSIVE 

3 

a  *  b  —  c 

ORI? 

OR? INCLUSIVE 

3 

a  +  b  —  c 

CA? 

COMPLEMENT?ADD 

2  * 

a  +  v  —  b 

ANV? 

AND?VALUE 

2  * 

a  .  v  —  b 

OEV? 

OR?EXCL? VALUE 

2  * 

a  *  v  —  b 

OIV? 

OR$INCL?VALUE 

2  * 

a  +  v  b 

Manipulative 

MW? 

MOVE?WORDS 

2 

* 

a  —  b,  - . .  ,a+n-l— b+n-1 

MWV? 

MOVE?VALUE 

1  * 

* 

v  —  a , . . . , v  —  a+n- 1 

COMMAND 


TYPE 


FUNCTION 


Mnemonic 

"English-like" 

A  I  R  M 

Manipulative 

MWR$ 

MOVE? REPEATEDLY 

2  * 

a  --  b, . . .  ,a  -*  b+n-1 

MB? 

MOVE? BYTES 

2  * 

Byte  1  -*•  b, . .  .  ,By  to 
n  -►  b+n-1 

MLB$ 

MOVE?LEFT?BITS 

2  * 

n  leftmost  bits  are 
moved  from  a  to  b 

MRBS 

MOVE?  RIGHT?BITS 

2  * 

n  rightmost  bits  are 
moved  from  a  to  b 

MBR$ 

MOVE? BYTE? RIGHT 

2  * 

Specified  byte  of  a 
is  moved  to  right¬ 
most  byte  of  b. 

Shifts : 

SLA$ 

SHIFT?LEFT?A 

1  * 

The  specified  regis¬ 
ters  are  shifted 
left  arithmetically. 

SRA$ 

SHIFT? RIGHT? A 

1  * 

The  specified  regis¬ 
ters  are  shifted 
right  arithmetically 

SLL$ 

SHIFT?LEFT?L 

1  * 

The  specified  regis¬ 
ters  are  shifted 
left  logically. 

SRL? 

SHIFT? RIGHT? L 

1  * 

The  specified  regis¬ 
ters  are  shifted 
right  logically. 

SLC$ 

SHIFT?LEFT?CIRC 

1  * 

The  specified  regis¬ 
ters  are  shifted 
left  circularly. 

SRC? 

SHIFT?RIGHT?CIRC 

1  * 

The  specified  regis¬ 
ters  are  shifted 
right  circularly. 
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COMMAND 


TYPE 


FUNCTION 


Mnemonic  "English-like"  A  I  R  M 


Shifts : 


3RP$ 

SHIFT$RIGHT$PROP 

1  * 

The  specified  regis¬ 
ters  are  shifted 
right  arithmetically 
with  the  sign  bit 
propagating . 

Sequence 

Control : 

CW  $ 

COMPARE$WORDS 

3  * 

Execution  control 
transfers  to  c  if  a 
"relation"  b  is  true. 

CBS$ 

COMPARESBYTES 

3  *  * 

Execution  control 
transfers  to  c  if  Byte 
string  a  "relation" 
Byte  String  b  is  true. 

CLB$ 

COMPARELEFTBITS 

3  *  * 

Execution  control 
transfers  to  c  if  Bit 
String  a  "relation" 

Bit  String  b  is  true 

CRB$ 

COMPARERIGHTBITS 

3  *  * 

Execution  control 
transfers  to  c  if  Bit 
String  a  "relation" 

Bit  String  b  is  true. 

CWV$ 

COMPARES VALUE 

2  *  * 

Execution  control 
transfers  to  c  if  a 
"relation"  v  is  true. 

CL$ 

COMPARE$LIMITS 

3  * 

Execution  control 
transfers  to  c  if  a 
"relation"  b  and  b+1 
is  true. 

J$ 

JUMPS 

1 

Unconditional  trans¬ 
fer  to  a. 

Execution  control 
transfers  to  a  if 
the  overflow  indica¬ 
tor  is  set. 


J$,V 


JUMP$, OVERFLOW  1 


* 


COMMAND 


TYPE 


FUNCTION 


Execution  control 
transfers  to  a  if  b 
is  positive. 

Execution  control 
transfers  to  a  if  b 
is  negative. 

Execution  control 
transfers  to  a  ir  u 
is  zero. 

Execution  control 
transfers  to  a  if 
b  is  non- zero. 

Call  subroutine  a;  put 
return  address  in  b; 
calling  sequence  is 
at  c. 

Returns  v  cells  bey¬ 
ond  subroutine 
return  address  a. 

Execution  control 
transfers  to  a  if 
register  b  is 
decremented . 

Execution  control 
transfers  to  a  if 
register  b  is 
incremented. 

Execution  control 
transfers  to  a  if  b 
"relation"  v  is  true. 
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COMMAND 


TYPE 


FUNCTION 


Menmonic  "English-like"  A  I  R  M 
Miscellaneous : 

1$  INPUT$  3  The  specified  quantity 

of  data  is  input  from 
the  selected  input 
device  to  the  speci¬ 
fied  destination. 

0?  OUTPUT$  3  The  specified  quantity 

of  data  is  output  on¬ 
to  the  selected  out¬ 
put  device  from  the 
specific  location. 

XCH$  EXCHANGE$  2  *  The  specified  number 

of  words  starting  at 
a  and  b  are  inter¬ 
changed  . 

XEC$  EXECUTE$  2  The  instructions 

starting  at  a  down  to 
b  are  executed . 


Instructions  of  less  general  applicability  which  may  be  includ¬ 
ed  are : 

•  Floating  point  arithmetic 

•  Peripheral  equipment  controls  (rewind,  backspace) 

•  Stack  oriented  instructions  (PUSH, PULL) 

•  Conversion  operations 

•  Search  operations 

In  all  instances,  the  suggestions  made  in  previous  sections 
regarding  parameterization  and  general  coding  techniques  may  be 
incorporated  into  programs  written  in  macro  languages. 

Some  of  the  benefits  which  are  to  be  expected  from  this  approach 
include : 

•  An  awareness  of  transferability  considerations  before 
and  during  coding. 

•  Relatively  efficient  use  of  original  target  computer 
architecture. 

•  Programs  which  are  "very"  transferable  to  machines  of 
like  architecture. 

•  Feasible  transfer  of  programs  between  machines  of 
different  architectures  (assume  some  loss  or  trade¬ 
off  of  efficiencies). 

•  Standardization  of  assembly  mnemonics  and  formats  to 
reduce  re-training  costs. 

•  A  basis  for  quantitative  analysis  of  costs  of  trans¬ 
fer  versus  efficient  use  of  machine  characteristics 
(especially  when  considering  the  purchase  of  new 
hardware) . 

•  Possible  check-out  of  programs  for  "un-implemented" 

or  currently  unavailable  machines  on  another  computer. 

•  A  recognizable  starting  point  on  which  to  base  addi¬ 
tional  transferability  effort. 
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2.4.8  Policy 

Major  hardware  advances  in  a  relatively  short  period  of  time 
have  magnified  and  confused  the  problems  of  program  transfer- 
ability.  Basic  assembly  languages,  because  of  their  inherent 
references  to  unique  hardware  designs,  have  presented  the 
most  acute  obstacles  to  these  changes. 

The  urgency  associated  with  this  problem  seems  to  have  been 
responsible  for  the  after-the-fact  attributes  common  to  many 
current  efforts.  These  range  from  source-to-source  transla¬ 
tion  through  complete  re-coding.  Generally,  these  approaches 
have  been  costly,  machine  specific,  and  only  partially  effect¬ 
ive.  It  seems  desireable,  therefore,  to  redirect  efforts  at 
assembly  language  program  transfer  to  the  pre-program  design 
stage . 

This  implies  that  assembly  level  programmers  must  be  made  aware 
of  the  potential  for  system  transfer  and  the  effect  of  their 
coding  techniques  on  the  success  of  such  ventures. 

Similarly,  each  programming  organization  must  develop  standards 
for  design  and  coding  of  assembly  language  programs  as  they 
have  done  for  COBOL,  FORTRAN,  and  JOVIAL.  The  programmers 
should  be  encouraged  to  help  develop  these  standards. 

Additional  areas  where  standardization  might  be  imposed  in¬ 
clude  the  actual  assembly  languages  and  the  equipment  to  which 
they  are  so  closely  related.  It  seems  restrictive  and  unwise 
to  require  manufacturers  to  structure  their  hardware  to  be 
consistent  with  «_  standard  assembly  language.  On  the  other 
hand,  it  does  seem  possible  to  design  a  standard  pseudo¬ 
assembly  language.  Although  this  was  discussed  in  Section 
2.4.7,  some  additional  comments  seem  appropriate  at  this  time. 

An  unquestionably  important  factor  in  the  success  of  assembly 
program  transfer  is  the  programmer's  individual  awareness  and 
involvement.  The  use  of  universal  assembly  language  with 
machine  independent  aspects  is  a  possible  method  of  solidifying 
these  feelings.  The  knowledge  that  the  language  being  used 
can  be  modified  and  improved  by  the  programmer  may  engender 
such  efforts  (at  least  many  have  expressed  this  desire). 

Similarly,  the  wide  spread  and  often  costly  pre-occupation 
with  "tricky",  "shorter"  or  "faster"  coding  algorithms  could 
conceivably  be  diverted  to  the  development  of  "independence" 
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algorithms.  Dedication  to  the  invention  of  clever  ways  to 
perform  seemingly  machine  dependent  functions  in  a  universal 
or  parameterized  manner  is  certainly  desireable. 

Hence,  the  development  and  use  of  a  standard  assembly  language, 
when  combined  with  an  awareness  of  transferability  oriented 
ceding  techniques,  could  result  in  significant  improvements. 

A  recognizable  effort  in  this  area  could  influence  machine 
manufactures  toward  partial  standardization  of  character  sizes, 
object  formats,  machine  code  mnemonics,  etc. 

Unfortunately,  there  will  undoubtedly  always  be  programs  to 
which  these  techniques  do  not  apply.  Airborne  computer  appli¬ 
cations,  for  instance,  are  often  so  limited  in  resources  and 
application  dependent  that  efforts  at  transferability  would  be 
wasted.  There  is  considerable  area  for  improvement,  however. 
Elegant,  abstruse  programs  written  by  the  experienced  coder  to 
save  a  little  time  or  space  and  unr -jcessarily  complex  concoc¬ 
tions  produced  by  the  inexperienced  programmer  through  ignor¬ 
ance  can  both  be  eliminated.  In  the  area  of  assembly  level 
transferability,  any  improvement  will  be  a  major  one. 
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APPENDIX  A 


FORTRAN  Program  Transfer 


A  small  FORTRAN  program  was  prepared,  compiled  and  executed  on 
several  machines  as  part  of  this  study.  Each  of  the  statements 
in  the  program  would,  theoretically,  compile  and  execute  "as 
expected"  on  at  least  one  major  computer's  FORTRAN  System.  All 
statements  which  would  not  compile  properly  or  which  were  re¬ 
jected  by  the  compiler  were  removed  from  the  program  before  re¬ 
compilation  and  execution. 

It  should  be  noted  that  otner  compiler  versions  of  many  of  the 
computer  systems  utilized  would  display  different  results.  It 
is  also  interesting  that  no  particular  patterns  can  be  realis¬ 
tically  formed  from  these  results.  Even  more  advanced  compilers 
rejected  some  statements  found  acceptable  to  other  more 
"primitive"  systems. 

A  summary  of  the  features  of  this  transfer  which  would  pose 
obvious  transferability  difficulties  follows.  In  the  first 
chart.  Compilation  Characteristics,  several  definitions  are 
used. 

F  -  The  compiler  flagged  this  statement  or  function  as 
a  probable  error. 

R  -  The  compiler  rejected  this  statement  and  produced 
no  output  for  it. 

A  -  The  compiler  accepted  (compiled)  this  statement 
without  special  notes,  errors,  warnings,  etc. 

I  -  The  compiler  literally  ignored  the  non-standard 

aspects  of  this  statement.  For  instance,  INTEGER*2 
was  read  as  INTEGER. 
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APPENDIX  B 


Transferability  Factors 

•  Operating  system  interfaces 

•  Dialects,  extensions,  subsets  and  abbreviations  in  higher 
level  languages 

•  Code  restraints  imposed  by  interpretation  of  language 
standards 

•  Character  set  differences  -  internal,  tape,  and  card 
representations  and  collating  sequences 

•  Internal  clock  units 

•  Recording  modes  -  record  sizes,  block  sizes,  densities, 
parities,  control  words,  file  limits,  volume  sizes,  carriage 
controls,  end  of  the  line  marks,  etc. 

•  Computer  speed 
»  Core  size 

•  Peripherals  -  number  and  type 

•  Sense  devices  -  switches,  lights,  etc. 

•  Operator  interface 

•  Printer  speed  and  line  size 

•  Negative  number  representations 

•  Internal  number  representation  (packed  decimal,  binary,  etc.) 

•  interrupts  -  types,  mechanisms  and  priorities 

•  Boundary  alignment  -  halfword,  doubleword 

•  Condition  codes,  overflow  bits,  and  ether  indicators 

•  Channel  processing 

•  Memory  types  ~  ROM,  scratchpad,  etc. 
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•  Instruction  repertoires 

•  Variable  word  length  instructions 

•  Div^.  ,  ton/multiplication  algorithms 

•  Rounding 

•  Shifting  algorithms 

•  Absolute  addressing 

•  Relative  addressing 

•  Indirect  addressing  (with/without  index,  etc.) 

•  Dynamic  instruction  modification 

•  Address  size 

•  Page  size 

•  Direct  value  size 

•  Word  size 

•  Character  size 

•  Object  format 

•  Indexing 

•  Register  schemes 

•  Pre-ini tialized  memory 

•  Micro-programs 

•  Input/output  timing  controls 
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APPENDIX  C 

Software  Products  Synopses 


These  synopses  are  presented  as  a  sample  guide  to  the  general 
nature  of  commercial  conversion  services  and  products.  Capa¬ 
bilities  and  limitations  are  listed  by  way  of  example  and  are 
not  intended  to  reflect  the  exact  attributes  of  the  associated 
products.  A  choice  of  conversion  aids  should  not  be  limited 
to  or  influenced  by  this  material. 

AED  Cross  Compilers 
SoftTech,  Inc. _ 


AED  languages  feature  a  high  degree  of  modularity  with  target 
language  modules  treated  as  off-the-shelf  software  components. 


BASIC  to  FORTRAN  Translator 
International  Conversion  Systems 

Translates  BASIC  language  to  FORTRAN  on  a  timesharing  system  to 
provide  t.ne  facilities  of  BASIC  to  IBM  360  users. 


BCD  to  EBCDIC 

International  Business  Machines 


Converts  BCD  punched  cards  to  EBCDIC  format. 


BIAS  -  Basic  Iterative  Assembler  for  DEC  PDP-11 
COMP AT A,  Inc. _ 


"Can  be  used  on  any  host  computer  which  supports  ASA  standard 
FORTRAN"  with  23  bits  plus  sign  precision,  card  reader,  card 
punch,  printer  and  one  tape. 


BIRS  -  Basic  Indexing  and  Retrieval  System 
Information  System  Laboratory,  Michigan  State  University 

This  collection  of  150  FORTRAN  routines  includes  the  TRAC  debug 
tool.  TRAC  is  written  in  FORTRAN  and  is  a  pre-compiled  debug 
tool  for  FORTRAN  programs.  This  highly  machine  independent 
program  provides  sophisticated  loop  detec' :^n  printouts  and 
diagnostics  • 
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BUFF40X 

Nanodata  Corporation 


A  special  fast  FORTRAN  compiler  with  enhanced  printouts  of 
storage  allocation,  expanded  diagnostics,  traces,  timing,  etc. 
Operates  on  IBM  360/25  and  up. 


CATALIST  -  Autocoder  to  BAL  Translator 
International  Business  Machines 


A  conversion  aid  for  transition  from  IBM  1401  Autocoder  to 
IBM  360  BAL. 


COM/FORT  Programming  Aids 
ADAPT,  Inc. _ 


Subroutines  designed  to  interface  commercial  applications  with 
FORTRAN  to  extend  the  standard.  They  can  also  be  invoked  via 
BAL,  COBOL  and  PL1  and  increase  speed  and  remove  input/output 
restrictions  such  as  record  sizes.  They  run  under  DOS  or  TOS. 


COBOL  Language  Conversion  Program  for  IBM  1401 
International  Business  Machines 


Facilitates  transition  to  IBM  360  by  converting  COBOL  source 
written  for  IBM  1401  to  System  360  Level  E  or  Level  F. 


DECIBLE  III 

Independence  Computing  and  Software 

General  decision  table  processor  written  in  COBOL. 


DST-11 

Decision  Science,  Inc. 

Cross  assembler  for  PDP-11  written  in  FORTRAN. 
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International  Computer  Systems 


A  procedure  oriented  macro  processor  with  extensive  cross¬ 
assembly  and  language  generation  facilities.  Largely  uost  and 
target  machine  independent. 


DUO  360/370 

Computer  Technology/  Inc. 

The  DUG  package  enables  the  user  to  run  IBM  360/370  DOS  object 
programs,  without  modif ication ,  under  OS  and  to  use  the  OS 
features  via  JCL. 


EXODUS  I  and  EXODUS  II 
Computer  Sciences  Corporation 


Respectively  translate  IBM  1410  and  1401/40/60  AUTOCODER  or  SPS 
source  to  IBM  System  36C  BAL. 


HELP  -  Highly  Extendable  Language  Processor 
Advanced  Computer  Techniques  Corporation 


Allows  programmer  to  define  extensions  to  FORTRAN,  COBOL  and 
PL1  via  macro  definitions.  Translates  extended  statements  to 
conventional  language  forms  in  a  pre-compile  phase. 


IBM  7040/7044  Emulator  Program 
International  Business  Machines 


The  emulation  is  performed  on  the  System  360  and  consists  of 
the  emulator  program  and  special  machine  additions  called  the 
7040  compatibility  feature. 


MECCA  360/370 
Arkay  Computer  At 


>lications 


"Monitor  and  Enforce  Conformance  to  COBOL  Administrative"  stand 
ards.  Inspects  COBOL  source  for  conformance  to  200  management 
selected  standards  and  lists  corresponding  severity  codes  and 
messages.  Reserved  words  (abbreviations)  can  be  prescribed. 
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MASTRAN 

National  Information  Systems ,  Inc. 

1401  AUTOCODER  to  System  360  BAL  conversion  service.  "No  charge 
for  less  than  90%  conversion." 


METAPLAN 

Proqrammatics,  Inc. 

A  procedure  oriented  macro  language  assembler  with  machine 
independent  attributes. 


MINI-SIM 

Trippe  Systems  Incorporated 

A  360  BAL  program  for  simulating  a  variety  of  mini  computer 
programs  including  control  panels.  Allows  use  of  360  peripherals 
by  mini  program  for  rapid  checkout. 


OPTIMAIL 

Clasco  Systems,  Inc. 

COBOL  source  program  optimization  by  mail.  Promises  z5s  re¬ 
duction  in  computer  time. 


OPTIMIZER 
CAPEX  Corporation 

Global  analysis  of  IBM  360/370  COBOL  compiler  object  output 
to  minimize  object  code  (time/core). 


PASSPORT 

Creative  Computing  Techniques 

A  general  software-assisted  program  conversion  service  based 
on  pattern  matching  of  source/destination  templates  for  various 
languages  and  machines.  Conversion  templates  are  tailored  to 
customer  habits,  and  CCT  personnel  assist  in  manual  work. 
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PL1  Checkout  Compiler 
International  Business  Machines 

PLl  program  modules  translated  by  this  product  run  more  effi¬ 
ciently  and  can  be  link-edited  with  output  modules  from  OS 
FORTRAN  and  COBOL. 


REPRIEVE 

National  Information  Systems 

A  software  package  which  allows  RCA  TDOS  users  to  convert  to 
IBM  3t>0/370  without  modification  or  system  regeneration. 


SIFT 

SCARE 

Operates  on  FORTRAN  II  source  decks  to  produce  basic  FORTRAN 
IV  source. 


STAGE  II 

Optimization  Sciences,  Inc. 

COEOL  source  program  optimizer  to  reduce  run  time  and  core  size 
by  suggesting  programmer  changes  to  the  code. 


TACOS 

Management  Systems  Corporation 

Translates  AUTOCODER  76  to  IBM  360  COBOL  for  OS.  Handles  about 
90%  of  source  statements. 


TOTALTRAN 

CPU  Management  Advisory  Corporation 

Translates  1401  object  decks  to  System  360  assembly  source. 
Includes  disassemblers  to  produce  AUTOCODER  source  from  patched 
1401  or  7070  object. 
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TRANSEMBLER 
Code,  Inc. 


Cross  assembly  for  the  Varian  620/f  written  in  FORTRAN. 


Universal  Assembly  System  for  One-Address  Minicomputers 
Jack  R.  Guskin,  International  Business  Machines 
(Not  an  IBM  Product) _  _ 


Uses  a  well-defined  fixed  syntax  and  dynamically  modified  seman¬ 
tics  dependent  upon  target  machine  characteristics. 


UPGRADE 

Information  Management,  Inc. 


De- compile 
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source.  Includes  manual  pre-translation, 
with  flags,  manual  post-translation . 


machine  translation 
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Document  Synopses  and  Bibliography 


BALZER,  R.  M. 

'ataiess  Programming 

All  data  and  function  references  are  expressed  in  a  single  can¬ 
onical  form  so  that  the  alteration  of  a  data  representation  has 
no  syntactic  effect  on  the  program.  A  PL/1  extension. 


BARTON,  M.  E. 

SWAP  :  The  Macro  As^r-mhler 

Examples  of  features  included  in  a  macro  assembler.  Recursive 
function  definition,  ellipsis  notation  for  arbitrary  number  of 
arguments,  character  string  partitioning  and  naming  are  mention¬ 
ed.  Includes  a  3%  page  listing  of  "A  SWAP  Program  to  Inter- 
pretively  Process  a  FORTRAN  Like  Language".  Points  out  that 
macro  facilities  do  not  have  to  be  out  of  reach  of  the  average 
user  programmer. 


BELL,  C.  GORDON  AND  ALLEN  NEWELL 
Computer  Structures:  Readings  and  Examples 

...presents  many  examples  of  computer  systems... in  enough 
detail  (for)  meaningful. . .study  and  analysis. . .using  the 
original  descriptions ... in  the  technical  literature.  Collected 
comparisons  of  machine  features,  some  of  which  are  pertinent 
to  transferability.  (Those  not  transparent  to  the  program.) 


BEMER,  ROBERT  W. 

Program  Transferability 

Program  Transfer  is  complicated  by  each  element  which  is  differ¬ 
ent.  Programs  must  be  planned  for  transfer. .. (has)  not  yet 
been  successful  mechanical  translation  of  machine  language 
program.  Lists  information  needed  to  transfer  (run)  a  program. 
Suggests  tools  for  conversion  checkout.  Suggests  that  compiler 
should  capture  information  and  describe  its  own  peculiarities. 
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DELLERT,  GEORGE  T.  JR. 

A  Use  of  Macros  in  Translation  of  Symbolic  Assembly 
Language  of  One  Compiler  to  Another 

A  set  of  macros  used  to  help  translate  IBM  7090  Assembly 
Language  to  IBM  7040  Machine  Language. 


DONOVAN,  JOHN  J.  AND  HENRY  F.  LEDGARD 
A  Formal  System  for  the  Specification  of  the  Syntax 
and  Translation  of  Computer  Languages 

This  paper  deals  with  the  use  of  established  methods  of 
recursive  definition  to  present  a  single  method  to: 

1.  Specify  the  syntax  of  computer  languages. 

2.  Specify  the  translation  of  programs  in  one 
computer  language  into  programs  in  another 
language. 


ELSPAS,  BERNARD,  MILTON  GREEN  AND  CARL  LEVITT 
Software  Reliability 

We  examine. . .approaches  to  improving  the  art  of  computing, 
debugging  and  verifying  programs ,... improvements  in  program¬ 
ming  languages, .. .debugging  techniques  that  incorporate 
semantic  analysis  in  the. . .compilation, .. .possibilities  for 
the  logical  proof  of  the  correctness  of  a  program. 


ENGLANDER,  WILLIAM  R. 

How  Standard  are  COBOL  Compilers? 

COBOL  compiler  validation  system  (Air  Force)  used  to  audit 
computers  for: 

B2500/B3500  COBOL 
GE  625/635  COBOL 
S/360  COBOL  F 
UNIVAC  1108  COBOL  EXEC  II 

Test  failures  are  reported  without  identifying  which  compiler. 
Suggests  using  CCVS  to  select  both  a  compiler  and  those  features 
to  be  avoided  as  not  compatible. 
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ERICKSON,  BEVERLY 
A  Program  Disassembler 


The  concept  of  object  program  disassembly  is  presented  as  the 
final  step  in  a  series  of  three  utility  programs.  Flowcharts 
and  examples  are  included. 

FALOR,  KEN 

Survey  of  Program  Packages 

Lists  source,  name,  description,  computer,  compiler  and  price 
for  software  items  in  the  categories  conversion,  translation 
and  simulation  programs  (19  items);  debugging  and  testing  pro¬ 
grams  (23  items);  JCL  compilers  (6  items);  documentation  and 
flowchart  producing  programs  (12  items);  languages  (17  items); 
preprocessors  for  decision  tables,  shorthand  languages,  etc. 
(19  items);  other  general  purpose  programming  aids  (14  items). 


FERGUSON,  DAVID  E. 

Evaluation  of  the  Meta-Assembly  Program 

A  generalized  meta  assembler  is  described.  Evolution  of  the 
assembly  program  and  its  implication  to  compiler  design  are 
discussed . 


FRITZ,  W.  BARKLEY 

Computer  Change  at  Westinghouse  Defense  and  Space  Center 
Management  guidelines  for  transferability. 


FUJII,  ATSUSHI 

Software  in  Japan:  Supported  Growth 

The  Japanese  Government  xs  encouraging  and  supporting  software 
development  in  several  ways.  A  new  organization  will  buy  soft¬ 
ware  packages  from  developers  and  lease  them  to  users.  The 
government  thus  assumes  the  majority  of  the  risk.  The  govern¬ 
ment  gives  examinations  for  information  processing  engineers. 

In  the  test  for  programming,  FORTRAN,  COBOL  or  Assembly  Language 
could  be  chosen  for  solving  the  problems.  The  Japanese  Govern¬ 
ment  has  launched  a  5-year  project  (large  Industrial  Engineering 
development)  to  upgrade  the  technology  of  the  Japanese  informa¬ 
tion  processing  industry.  One  program  is  for  the  development 
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of  common,  hardware  independent,  software.  FORTRAN,  COBOL  and 
PL/I  compilers  written  in  a  subset  of  PL/I,  translate  to  a 
common  hardware  independent  intermediate  language.  Hardware 
dependent  compilers  translate  the  intermediate  language. 


GAINES,  R.  STOCKTON 

On  the  Translation  of  Machine  Language  Programs 
Four  classes  of  problems  in  translation: 

1.  Untranslatable  segments,  e.g.  a  core  memory  test 
for  a  particular  machine. 

2.  Idiomatic  expressions,  e.g.  the  conversion  of  an 
integer  to  floating  point  on  the  CDC  1604  by  doing 
an  integer  add  and  floating  subtract  of  a  particular 
constant. 

3.  Program  self-modification,  e.g.  altering  an  address 
or  an  operation  code  in  an  instruction. 

4.  Differences  in  machine  design,  e.g.  different  word 
sizes,  different  instruction  details. 

Discusses  simulation  and  automatic  translation  (of  a  programmer 
pre-edited  source  deck  followed  by  programmer  debugging)-  The 
problem  statements  suggest  a  partial  answer:  Syntax  should 
accurately  reflect  semantics,  e.g.  'Float'  vice  'integer  add, 
floating  subtract' .  Such  can  best  he  done  with  macros. 


GODSEN,  JOHN  A. 

Software  Compatibility:  What  Was  Promised,  What  We  Have, 

What  We  Need 

In  very  general  terms,  this  paper  defines  compatibility; 
defines  kind  of,  degree  of,  extent  of  and  direction  of  com¬ 
patibility;  lists  zones  of  compatibility  ranging  from  one 
installation  of  a  computer  to  all  computers  in  Air  Force  Logis¬ 
tics  Command;  lists  seven  implicit  promises  made  by  producers 
of  higher  level  languages  anu  the  extent  to  which  the  promises 
were  kept. 
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GODSEN ,  JOHN  A. 

Software  Compatibility 

The  subject  of  this  paper  is  data  compatibility. 


GRAHAM,  MARVIN  LOWELL  AND  PETER  ZILAHY  INGERMAN 
An  Assembly  Language  for  Reprogramming 

Describes  an  early  Meta-assembler. 


CRIES ,  DAVID 

Compiler  Construction  for  Digital  Computers 

Theory  •  •nd  examples  of  higher  level  language  compilers  design 
including  syntax,  semantics,  optimization,  interpretive 
techniques  and  macros. 

GRUEN BERGER,  FRED 
Problems  and  Priorities 

The  problems  facing  the  computer  industry  as  of  1972  are  listed 
in  order  of  importance.  Language  standardization  is  given  the 
loves t  priori ty . 


GUSKIN,  JACK  R. 

A  Uni-Language  for  a  General  Purpose  Assembly  Translator 
System  for  Single  Address  Machines 

A  discussion  of  translators  capable  of  accepting  a  variety  of 
source  languages. 

HAL3TE£  '  MAURICE  H. 

Machi  ’eperdence  and  Third-Generation  Computers 

An  exai-:  *  ase  of  a  decompiler,  converting  to  NELIAC. 


HALSTEAD,  MAURICE  H. 

Using  the  Computer  for  Program  Conversion 

Discusses  decompilers  which  accept  an  absolute  binary  program, 
analyze  it  in  great  detail,  translate  it  into  an  equivalent 
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program  in  a  higher  level  language  and  flag  ambiguities.  Dis¬ 
cusses  the  economics  of  writing  and  using  a  decompiler. 

HARPER,  WILLIAM  !• . 

Documentation  for  Application  Programming 

The  function  of  documentation  is  defined  in  general  terms. 


HICKS,  HARRY  T.  JR. 

ANSI  Cobol 

Discusses  the  levels  of  ANSI  COBOL,  compiler  validation,  and 
the  transition  from  prestandard  COBOL.  The  arrival  of  the 
ANSI  COBOL  compilers  will  require  many  COBOL  users  to  convert 
their  existing  programs.  The  organization  can  adopt  a  stand¬ 
ard  dialect  to  facilitate  programmer  training  and  make  avail¬ 
able  a  richer  choice  of  future  computers  and  compilers. 

HOPPER,  GRACE  MURRAY 

Standardization  of  High-Level  Languages 

The  common  element  essential  tc  mobility  is  the  establishment 
of  standards  for  programmers,  programs,  and  documentation. 

JONES,  RONALD  W. 

Generalized  Translation  of  Programming  Languages 

A  generalized  model  for  the  computer  translation  of  both  pro¬ 
gramming  and  natural  languages  has  been  developed  at  the 
Linguistics  Research  Center  of  the  University  of  Texas.  The 
theory  says  there  are  two  structures  underlying  a  language  - 
surface  structure  and  basic  structure. 


LEE,  JOHN  A.  N. 

The  Anatomy  of  a  Compiler 

An  author  who  has  written  many  practical  language  processors 
communicates  his  experience,  choosing  FORTRAN  as  an  example. 
The  exposition  is  concrete  (thoroughly  exemplified) ,  a  blend 
of  theory  and  practice. 


MEALY,  GEORGE  H. 
Another  Look  at  Data 


Proposes  theoretical  model  for  data  and  data  processing. 


MILLS,  HARLAN  D. 

Syntax-Directed  Documentation  for  PL  360 

The  language  PL  360  with  its  phrase  structure  grammar  is  used 
as  a  concrete  basis  for  illustrating  an  idea  called  Syntax- 
Directed  Documentation.  The  idea  is: 

1.  To  use  the  phrase  structure  of  a  program  to  define 
the  structure  of  a  formal  documentation  for  that 
program. 

2.  To  use  the  syntactic  types  and  identifiers  in  the 
resulting  structure  to  trigger  the  automatic  forma¬ 
tion  of  questions  to  the  programmer  whose  answers 
will  become  part  of  that  documentation. 

3.  To  provide  automatic  storage  and  retireval 
facilities . 

A  small  PL  360  program  is  worked  out  as  an  example. 


MORENOFF,  EDWARD 

The  Transferability  of  Computer  Programs  and  the 
Data  on  Which  They  Operate 

History  and  overview  of  RADC  interest  in  transferability. 


MULHOLLAND,  K.  A. 

Software  to  Translate  Telcomp  Programs  into  KDF9  Algol 

Lists  the  KDF9  Algol  statements  chosen  to  correspond  to 
Telcomp  statements.  Not  a  particularly  successful  effort. 


ORGASS,  RICHARD  J.  AND  WILLIAM  M.  WAITE 
A  Base  for  a  Mobile  Programming  System 

Describes  an  algorithm  for  a  macro  processor  which  has  been 
used  as  the  base  for  an  implementation,  by  boot  strapping,  of 
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processors  for  programming  languages.  This  algorithm  can  be 
easily  implemented  on  contemporary  computing  machines. 


RECTOR,  DR.  ROBERT  W.  AND  DR.  C.  J.  WALTER 
The  Fourth  -  Another  Generation  Gap? 

Some  anticipated  characteristics  of  fourth-generation  computer 
systems  are  briefly  discussed.  The  view  is  presented  that 
computer  designers  do  not  understand  the  needs  of  the  user; 
software  production  is  a  significantly  different  effort  from 
software  use  and  designers  tend  to  optimize  for  software 
production . 


REENSKAUG,  TRYGVE 

Some  Notes  on  Portable  Application  Software 

Notes  based  on  experience  with  the  AUTOKON  system  for  design  of 
ship's  hulls.  Three  methods  were  tried  -  reprogramming  -  time 
consuming,  expensive,  boring,  error  prone.  Generative  coding 
via  SLEUTH  II;  dropped  because  producing  relocatable  object 
decks  for  ill-documented  operating  systems  was  difficult  and 
decks  not  customer-maintainable.  High  level  language  now 
method  of  choice,  becoming  restricted  to  USASI  ’JASIC  FORTRAN. 
Equivalence  between  real  and  integer  arrays,  low  precision  real 
have  caused  problems.  Peculiar  restrictions  on  FORTRAN  unit 
numbers,  paper  tape  not  well  supported.  Operating  systems 
have  strong  opinions  about  disc  data  physical  organization. 


SABLE,  JEROME  D. 

Transferability  of  Data  and  Programs  Between  Computer  Systems 

The  problem  of  transferring  data  and  interpreting  it  can  be 
approached  by  constructing  an  adequate  range  of  data  structure 
types  and  devising  a  standard  way  of  describing  these  types 
(Data  Description  Language). 


SATTLEY,  KIRK,  ET.  AL. 

On  Program  Transferability 

Suggestions  on  transferability  enhancements  effecting  the  total 
program  transfer  problem  with  emphasis  on  operating  systems. 
Prepared  for  RADC. 
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SHAW,  CHRISTOPHER  J. 

A  Comparative  Evaluation  of  JOVIAL  and  FORTRAN  IV 


Side-by-side  outline  of  the  advantages  and  capabilities  of  each 
language.  Identity,  applicability,  origin,  dialects,  structures, 
input/output  and  modularity  are  discussed  with  suggested  uses 
of  each  language.  Low-key  comments  regarding  portability  are 
included . 


SAMMET ,  JEAN  E. 

Programming  Languages:  History  and  Fundamentals 

An  overall  view  of  higher  level  languages.  This  book  brings 
together  in  one  place  fundamental  information  about  program¬ 
ming  languages,  including  history,  general  characteristics, 
similarities  and  differences,  as  well  as  detailed  technical 
descriptions.  The  book  contains  basic  information  and  provides 
perspective  on  120  higher  level  languages,  including  all  the 
major,  and  most  of  the  minor,  languages  developed  in  the  United 
States.  Major  languages  are  described  in  a  consistent  way, 
following  a  fundamental  outline  and  general  discussion  of  tech¬ 
nical  and  non- technical  characteristics  of  programming  languages. 


SCHAEFER,  MARVIN 

DBL :  A  Language  for  Converting  Data  Bases 

Describes  a  program  to  transfer  data  from  one  data  management 
system  to  another.  It  is  not  clear  from  the  article  whether 
it  will  handle  transfers  from  one  operating  system  or  one 
machine  to  another. 


SIEGEL,  STAN 

WAT FOR. . .Speedy  FORTRAN  Debugger 

WATFOR  is  a  FORTRAN  compiler  developed  by  the  University  of 
Waterloo,  Canada.  It  provides  diagnostics  on  usages  that  some 
FORTRAN  compilers  overlook  and,  by  chance  handle  "properly". 
It  shows  definite  transferability  oriented  design  in  the  areas 
of  code  restraints  and  standardization. 
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